談一個大型的互聯網應用系統使用的技術方案彙總（架構師應具備的基本常識）

開篇總得說點什麼

隨着現在技術的演進，分佈式微服務幾乎會出現在我們所見的任何大型互聯網應用系統中，單體應用幾乎再難以支撐我們現在的互聯網流量壓力。一個系統從單體應用逐漸發展成爲集羣架構，再慢慢的演變成分佈式微服務架構，技術上需要一系列的獨立系統與組件支持其運維發展。我們今天只從技術應用領域談一下一個大型的互聯網應用系統在發展過程中涉及到的技術方案與手段。

數據庫

一切的一切都是數據在說話，一個軟件架構離不開數據庫的支持。

1. 關係型數據庫：雖然最近NoSql很火，但是其一直替代不了關係型數據庫的位置。其原因就是因爲關係型數據庫強大的關係支持與早已很穩定的數據庫事務。代表作：Mysql、Oracle，並且一個應用系統建立之初肯定最先考慮關係數據庫的支持，在現在的工作場景中，開發、運維甚至測試和產品對標準sql 的掌握基本已成爲必備工作技能。
2. 非關係型數據庫和緩存數據庫：緩存數據庫算是一類特殊的非關係數據庫，例如Redis，memcached以其強大的內存性能常用來作爲系統提升的首選。Redis之於memcached算是後起之秀，redis具有更豐富的內容類型，並且每種類型都有自己的獨有的計算方法，以計算偏向於數據的方式可以減輕客戶端的壓力，存儲依然不夠了怎麼辦，還有Redis-cluster。另一類Nosql數據庫MongoDb我們常會用到類似於文檔存儲的場景。
3. 分佈式數據庫:在單機mysql達到極限的時候，這時候我們會考慮分庫分表以支持數據的擴張，這也是一種分佈式的數據存儲方案。市面上針對不同的場景也有很多分佈式數據庫產品會用到，例如HDFS、FastDFS等，有時爲了處理HDFS與sql之間的差異轉換問題，可能會用到hive等產品。
4. 聚合數據庫：當分庫分表方案用盡了的時候，我們還能用什麼？ES應該算是一種特殊的數據庫，雖然他的出生主要是以聚合分析爲主，通過倒排索引提高數據檢索的速度，但是終究離不開數據的存儲，所以也可以勉強把其歸爲數據庫的一種。
   

消息中間件

分佈式系統中解決不同系統之間通訊少不了的就是消息中間件。可以分爲無代理消息架構與有代理消息架構。目前我們基本常用到的是有代理消息架構，類似產品RocketMq、Kafka、ActiveMq等。

分佈式事務

分佈式中最難解決的可能就是分佈式事務，最終可能通過一系列柔性事務去解決最終一致性問題，犧牲性能以獲得數據的準確性。目前比較或的一些框架有阿里的seata、gts等，或是通過業務上的一些手段例如XA、TCC、多階段提交來解決。

分佈式鎖

分佈式鎖的實現方式主要有幾種，1、基於mysql實現 2、基於zk實現 3、基於Redis實現 4、基於etcd實現

分佈式ID

作用不多說，常用到的例如snowflake，美團的leaf也是基於此基礎來的。

任務調度中心

一個分佈式系統中我們需要由對定時任務進行批量管理，手動停止、啓動、詳情等的管理調度中心。例如xxl-job

配置中心

都分佈式集羣了，零散的配置肯定不能項目自己管理了。配置中心這時候就可以很好的維護起配置文件的作用。常用的apollo，spring cloud config

註冊中心

在微服務架構裏註冊中心主要起到了協調者的一個作用；例如zookeeper、eureka

網關

作爲流量的入口，統一的處理和業務相關的請求，讓請求更加安全、快速和準確的得到處理。例如kong，spring zuul

服務監控

微服務系統一旦請求出現異常，我們必須得知道是在哪個服務環節出了故障，這樣我們就需要對每一個服務，以及各個指標都進行全面的監控。我們常用到的會有 Prometheus，在這之前我們還用過zabbix、openfalcon等。

全鏈路跟蹤

在微服務架構中，一個服務鏈路調用起來特別長，可能會涉及到多個服務，這時候查找問題需要全鏈路跟蹤的出現了，我們叫他 APM系統。有Twitter開源的ZipKin，國內skywalking等都是優秀的組件。

熔斷、降級、限流

熔斷、降級、限流三個似乎總是一起出現，但是他們三個又都各司其職。熔斷參考的生活中短路保護器的原理，當下遊發生故障時，及時算開鏈路防止造成更大的影響，當它監控到調用下游的服務異常會根據策略進行適當的保護下游，採用防護下游系統的方式來間接保護自己被hang住太多超時的請求，他的策略有三種狀態，全開、全斷、半開狀態。降級可以在熔斷之後爲服務自動觸發降級以保護系統，同時我們也可以採用手動降級的方式，防止在服務熔斷時再採取措施，這個方法很好用，大家記住。限流指的是限制達到系統的併發數量，限流的算法你至少應該知道 ：窗口、漏斗、令牌桶等等。

負載均衡

將流量轉發到多個服務器來提高系統的可用性。可以分爲三類，1、地域上的負載 DNS；2、硬件的負載 例如F5，做的是集羣與集羣間的負載；3、軟件層面的負載，常用到的有nginx 和 lvs 分別工作在應用層 和 傳輸層 。

總覺得還有什麼沒說到

在一個大型的分佈式系統中，我們還會用到 CDN 作爲緩存動靜分離使用，在lvs內部我們也應該知道VIP（虛擬IP技術）的原理和應用，同時我們還會考慮到Keepalived 和Haproxy作爲系統高可用和負載的技術方案。

最後的最後

似乎總有用不完的手段，在整個水平擴展的架構再無新鮮之處外，正在逐漸火熱的響應式異步編程正在慢慢燃起。我們可以使用Reactor編程模型去重構我們的系統，基於Reactive目前主要有幾大框架，我們可以使用RxJava，Webflux等。目前springboot2.0之後主推的是webflux，受限於現在的JDBC等同步連接，我們可以使用netty進行一些改造，相信我們的系統單體性能可以提高几個數量級了。

似乎還有最後

技術一直在發展， 社會一直在進步，我們需要一直努力。總有人在創造，也總有人在生產，一堆堆的技術和方案其實都是爲了解決現實問題而生。技術似乎不會有最後，總感覺還是有什麼沒有想到，希望和您一起聊下去。。。