服務(wù)簡史

歷史總是驚人的相似，合久必分，分久必合。

[[272671]]

我們經(jīng)歷了“合”：單體架構(gòu)(軟)、計算能力超強(qiáng)的小型機(jī)(硬)到“分”：分布式架構(gòu)的轉(zhuǎn)變，后期可能會將“分”發(fā)揮到了極致(去中心化的分布式，如區(qū)塊鏈)，最后很可能再經(jīng)歷“合”：計算和存儲能力超強(qiáng)的“智人”(邊緣計算的升級，集超級計算和存儲一身的人工智能)。

那單體架構(gòu)為什么要演進(jìn)呢?筆者認(rèn)為主要體現(xiàn)在如下3點(diǎn)：

1.業(yè)務(wù)量在增加

互聯(lián)網(wǎng)發(fā)展對應(yīng)用開發(fā)提出了更高要求。業(yè)務(wù)的量級和效率提高，傳統(tǒng)的單體架構(gòu)將出現(xiàn)瓶頸。

2.能采集的信息越來越多

互聯(lián)網(wǎng)飛速發(fā)展的同時，也推動了云計算、大數(shù)據(jù)、人工智能的快速落地，數(shù)據(jù)采集遍布軟件、硬件，數(shù)據(jù)本身價值也得到提升。使用微服務(wù)架構(gòu)恰好解決了大部分痛點(diǎn)。

3.萬物互聯(lián)

數(shù)據(jù)聯(lián)通性的需求：系統(tǒng)間，系統(tǒng)與硬件之間，數(shù)據(jù)對接必須保證高性能、高安全、高標(biāo)準(zhǔn).

微服務(wù)架構(gòu)

我們已經(jīng)意識到：技術(shù)架構(gòu)受公司業(yè)務(wù)和組織架構(gòu)影響。作為從單體架構(gòu)過來的人，起初我是拒絕的，或者說擔(dān)心我們的業(yè)務(wù)被拆分后出現(xiàn)不穩(wěn)定狀況。但是隨著業(yè)務(wù)突然擴(kuò)展，業(yè)務(wù)不斷細(xì)分，敏捷開發(fā)和配套的技術(shù)方案迫在眉睫。總歸是要邁出這第一步，2015年下半年，我們踏上了微服務(wù)的不歸路。

技術(shù)選型

首先根據(jù)總體業(yè)務(wù)規(guī)劃，我們先做了初步的技術(shù)架構(gòu)規(guī)劃，然后確定選型思路：

• 不綁定到特定的框架，跨語言
• 服務(wù)最好是Restful風(fēng)格(風(fēng)格極簡，且是主流標(biāo)準(zhǔn))
• 足夠簡單，容易落地，將來能擴(kuò)展
• 穩(wěn)定性強(qiáng)
• 和Docker相容性好(自動化運(yùn)維)

有了思路，根據(jù)我們的方法論，要根據(jù)現(xiàn)有的主流架構(gòu)做一番比較和篩選然后才能最終敲定：

1. Dubbo、DubboX：優(yōu)勢在于全棧、服務(wù)治理的支持性強(qiáng)，是阿里巴巴開源且經(jīng)過阿里巴巴實(shí)踐的產(chǎn)品，中文文檔很多，社區(qū)活躍。但選型時停止維護(hù)，跨語言難度較大
2. Spring Cloud：是Spring旗下的子項(xiàng)目，社區(qū)足夠強(qiáng)大，架構(gòu)本身簡單方便，幾乎零配置。基于RESTful API，跨語言。但當(dāng)時Spring Cloud實(shí)踐較少，且性能和RPC相比不占優(yōu)勢
3. Motan：是微博平臺微服務(wù)框架，承載了微博平臺千億次調(diào)用業(yè)務(wù)。優(yōu)勢在于性能，且實(shí)現(xiàn)模塊化、結(jié)構(gòu)簡單、易于使用、跨語言，但對于復(fù)雜的業(yè)務(wù)支持不夠好
4. Thrift、gRPC：并不能算作微服務(wù)框架，自身并不包括服務(wù)發(fā)現(xiàn)等必要特性
5. Istio：Service Mesh思想，可以看作是微服務(wù)架構(gòu)的一次升級，和serverless要解決的問題類似，讓業(yè)務(wù)/算法與服務(wù)治理剝離，當(dāng)時技術(shù)還不成熟(這個選型時后來補(bǔ)充的)

受限于當(dāng)時技術(shù)團(tuán)隊的資源限制，我們根據(jù)最小阻力原則，選擇了SpringCloud.spring cloud提供了開發(fā)分布式服務(wù)系統(tǒng)的一些常用組件，例如服務(wù)注冊和發(fā)現(xiàn)、配置中心、熔斷器、智能路由、微代理、控制總線、全局鎖、分布式會話等。如下圖所示：

架構(gòu)替換

經(jīng)過短期探索調(diào)試后準(zhǔn)備開始試水，暫時不敢動主流業(yè)務(wù)，我們就從對外提供的一些接口服務(wù)和部分獨(dú)立系統(tǒng)開始下手，這個階段我們嘗到了甜頭，但緊隨其后就是各種填坑，質(zhì)疑不斷，不過最后我們還是堅持下來。

構(gòu)建容器云支撐

微服務(wù)初步改造后，給我們帶來了一些額外困擾：

1. 微服務(wù)過多，服務(wù)治理成本高，不利于系統(tǒng)維護(hù)。
2. 分布式系統(tǒng)開發(fā)的技術(shù)成本高(容錯、分布式事務(wù)等)，對團(tuán)隊挑戰(zhàn)大。

顯然，我們不能通過jar包啟動的方式去維護(hù)大批量微服務(wù)，而且這些服務(wù)部署在一起還相互影響。

啥是配齊?容器云+微服務(wù)

在剛引入微服務(wù)后不久，我們并沒有急于替換所有業(yè)務(wù)，而是把基礎(chǔ)運(yùn)維工作做好，隨后我們引入了Docker。Docker給我們帶來了：

1. 迭代效率提升支撐：Docker 用戶發(fā)布軟件的頻率平均快了 7 倍
2. 環(huán)境可移植：Docker是一個代碼運(yùn)輸集裝箱系統(tǒng)，它使得通過Linux的軟件開發(fā)和交付變得很容易
3. 更快且更小：充分利用服務(wù)器資源，一臺虛機(jī)可以跑幾十個容器
4. 標(biāo)準(zhǔn)統(tǒng)一：可實(shí)現(xiàn)環(huán)境甚至架構(gòu)的復(fù)制性

光有Docker還不夠，我們發(fā)現(xiàn)引入Docker容器后，雖然解決了一些問題，但是還不夠。我們運(yùn)維起來太麻煩，各種Docker命令還有腳本，甚至我們都不知道我們到底有多少服務(wù)，它們健康狀態(tài)、資源占用怎么樣，當(dāng)業(yè)務(wù)量激增難道我們永遠(yuǎn)都是被動且手動的去做服務(wù)伸縮么?

我們隨后引入了容器編排工具：Rancher，并圍繞Rancher + Docker構(gòu)建了一套容器云和一套DevOps工具集(本文不做重點(diǎn)描述，歡迎關(guān)注后續(xù)文章)。

當(dāng)我們從大量運(yùn)維工作中解放出來后，我們發(fā)現(xiàn)，小團(tuán)隊也可以做大事情：

1. 小團(tuán)隊作戰(zhàn)，敏捷開發(fā)方式，替換其他業(yè)務(wù)
2. 解決方案打包，一鍵部署
3. 抽出人手構(gòu)建我們同等重要的DPaaS平臺
4. 部分業(yè)務(wù)變化快的模塊快速優(yōu)化甚至重構(gòu)

初見成果

雖然微服架構(gòu)替換現(xiàn)有業(yè)務(wù)說起來容易，但整個替換過程持續(xù)了將近2年，到了2017年底，我們已經(jīng)形成一套基于容器云和微服務(wù)架構(gòu)體系的解決方案，整體架構(gòu)如下圖所示：