微服務(wù)是否適合小團(tuán)隊(duì)是個(gè)見(jiàn)仁見(jiàn)智的問(wèn)題液荸。回歸現(xiàn)象看本質(zhì)脱篙，隨著業(yè)務(wù)復(fù)雜度的提高娇钱，單體應(yīng)用越來(lái)越龐大，就好像一個(gè)類(lèi)的代碼行越來(lái)越多绊困，分而治之文搂，切成多個(gè)類(lèi)應(yīng)該是更好的解決方法。

微服務(wù)是否適合小團(tuán)隊(duì)是個(gè)見(jiàn)仁見(jiàn)智的問(wèn)題秤朗∶翰洌回歸現(xiàn)象看本質(zhì)，隨著業(yè)務(wù)復(fù)雜度的提高取视，單體應(yīng)用越來(lái)越龐大硝皂，就好像一個(gè)類(lèi)的代碼行越來(lái)越多，分而治之作谭，切成多個(gè)類(lèi)應(yīng)該是更好的解決方法稽物。

所以一個(gè)龐大的單體應(yīng)用分出多個(gè)小應(yīng)用也更符合這種分治的思想。當(dāng)然微服務(wù)架構(gòu)不應(yīng)該是一個(gè)小團(tuán)隊(duì)一開(kāi)始就該考慮的問(wèn)題折欠，而是慢慢演化的結(jié)果姨裸，謹(jǐn)慎過(guò)度設(shè)計(jì)尤為重要。

公司的背景是提供 SaaS 服務(wù)怨酝，對(duì)于大客戶(hù)也會(huì)有定制開(kāi)發(fā)以及私有化部署傀缩。經(jīng)過(guò) 2 年不到的時(shí)間，技術(shù)架構(gòu)經(jīng)歷了從單體到微服務(wù)再到容器化的過(guò)程农猬。

單體應(yīng)用時(shí)代

早期開(kāi)發(fā)只有兩個(gè)人赡艰，考慮微服務(wù)之類(lèi)的都是多余。不過(guò)由于受前公司影響斤葱，最初就決定了前后端分離的路線(xiàn)慷垮，因?yàn)椴恍枰紤] SEO 的問(wèn)題，索性就做成了 SPA 單頁(yè)應(yīng)用揍堕。

多說(shuō)一句料身，前后端分離也不一定就不能服務(wù)端渲染，例如電商系統(tǒng)或者一些匿名即可訪(fǎng)問(wèn)的系統(tǒng)衩茸，加一層薄薄的 View 層芹血，無(wú)論是 PHP 還是用 Thymeleaf 都是不錯(cuò)的選擇。

部署架構(gòu)上，我們使用 Nginx 代理前端 HTML 資源幔烛，在接收請(qǐng)求時(shí)根據(jù)路徑反向代理到 Server 的 8080 端口實(shí)現(xiàn)業(yè)務(wù)啃擦。

接口定義

接口按照標(biāo)準(zhǔn)的 Restful 來(lái)定義：

版本，統(tǒng)一跟在 /api/ 后面饿悬，例如 /api/v2令蛉。

以資源為中心，使用復(fù)數(shù)表述狡恬，例如 /api/contacts珠叔，也可以嵌套，如 /api/groups/1/contacts/100弟劲。

url 中盡量不使用動(dòng)詞运杭，實(shí)踐中發(fā)現(xiàn)做到這一點(diǎn)真的比較難，每個(gè)研發(fā)人員的思路不一致函卒，起的名字也千奇百怪辆憔，都需要在代碼 Review 中覆蓋。

動(dòng)作支持报嵌，POST / PUT / DELELE / GET 虱咧，這里有一個(gè)坑，PUT 和 PATCH 都是更新锚国，但是 PUT 是全量更新而 PATCH 是部分更新腕巡，前者如果傳入的字段是空(未傳也視為空)那么也會(huì)被更新到數(shù)據(jù)庫(kù)中。

目前我們雖然是使用 PUT 但是忽略空字段和未傳字段血筑，本質(zhì)上是一種部分更新绘沉，這也帶來(lái)了一些問(wèn)題，比如確有置空的業(yè)務(wù)需要特殊處理豺总。

接口通過(guò) swagger 生成文檔供前端同事使用车伞。

持續(xù)集成(CI)

團(tuán)隊(duì)初始成員之前都有在大團(tuán)隊(duì)共事的經(jīng)歷，所以對(duì)于質(zhì)量管控和流程管理都有一些共同的要求喻喳。

因此在開(kāi)發(fā)之初就引入了集成測(cè)試的體系另玖，可以直接開(kāi)發(fā)針對(duì)接口的測(cè)試用例，統(tǒng)一執(zhí)行并計(jì)算覆蓋率表伦。

一般來(lái)說(shuō)代碼自動(dòng)執(zhí)行的都是單元測(cè)試(Unit Test)谦去，我們之所以叫集成測(cè)試是因?yàn)闇y(cè)試用例是針對(duì) API 的，并且包含了數(shù)據(jù)庫(kù)的讀寫(xiě)蹦哼，MQ 的操作等等鳄哭。

除了外部服務(wù)的依賴(lài)基本都是符合真實(shí)生產(chǎn)場(chǎng)景，相當(dāng)于把 Jmeter 的事情直接在 Java 層面做掉了纲熏。

這在開(kāi)發(fā)初期為我們提供了非常大的便利性妆丘。但值得注意的是锄俄，由于數(shù)據(jù)庫(kù)以及其他資源的引入，數(shù)據(jù)準(zhǔn)備以及數(shù)據(jù)清理時(shí)要考慮的問(wèn)題就會(huì)更多飘痛，例如如何控制并行任務(wù)之間的測(cè)試數(shù)據(jù)互不影響等等。

為了讓這一套流程可以自動(dòng)化的運(yùn)作起來(lái)容握， 引入 Jenkins 也是理所當(dāng)然的事情了宣脉。

開(kāi)發(fā)人員提交代碼進(jìn)入 Gerrit 中，Jenkins 被觸發(fā)開(kāi)始編譯代碼并執(zhí)行集成測(cè)試剔氏，完成后生成測(cè)試報(bào)告塑猖，測(cè)試通過(guò)再由 reviewer 進(jìn)行代碼 Review。

在單體應(yīng)用時(shí)代這樣的 CI 架構(gòu)已經(jīng)足夠好用谈跛，由于有集成測(cè)試的覆蓋羊苟，在保持 API 兼容性的前提下進(jìn)行代碼重構(gòu)都會(huì)變得更有信心。

微服務(wù)時(shí)代

服務(wù)拆分原則

從數(shù)據(jù)層面看感憾，最簡(jiǎn)單的方式就是看數(shù)據(jù)庫(kù)的表之間是否有比較少的關(guān)聯(lián)蜡励。例如最容易分離的一般來(lái)說(shuō)都是用戶(hù)管理模塊。

如果從領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)(DDD)看阻桅，其實(shí)一個(gè)服務(wù)就是一個(gè)或幾個(gè)相關(guān)聯(lián)的領(lǐng)域模型凉倚，通過(guò)少量數(shù)據(jù)冗余劃清服務(wù)邊界。

單個(gè)服務(wù)內(nèi)通過(guò)領(lǐng)域服務(wù)完成多個(gè)領(lǐng)域?qū)ο髤f(xié)作嫂沉。當(dāng)然 DDD 比較復(fù)雜稽寒，要求領(lǐng)域?qū)ο笤O(shè)計(jì)上是充血模型而非貧血模型。

從實(shí)踐角度講趟章，充血模型對(duì)于大部分開(kāi)發(fā)人員來(lái)說(shuō)難度非常高杏糙，什么代碼應(yīng)該屬于行為，什么屬于領(lǐng)域服務(wù)蚓土，很多時(shí)候非澈晔蹋考驗(yàn)人員水平。

服務(wù)拆分是一個(gè)大工程蜀漆，往往需要幾個(gè)對(duì)業(yè)務(wù)以及數(shù)據(jù)最熟悉的人一起討論负芋，甚至要考慮到團(tuán)隊(duì)結(jié)構(gòu)，最終的效果是服務(wù)邊界清晰嗜愈， 沒(méi)有環(huán)形依賴(lài)和避免雙向依賴(lài)旧蛾。

框架選擇

由于之前的單體服務(wù)使用的是 Spring Boot，所以框架自然而然的選擇了 Spring Cloud蠕嫁。

其實(shí)個(gè)人認(rèn)為微服務(wù)框架不應(yīng)該限制技術(shù)與語(yǔ)言锨天，但生產(chǎn)實(shí)踐中發(fā)現(xiàn)無(wú)論 Dubbo 還是 Spring Cloud 都具有侵入性。

我們?cè)趯?Node.js 應(yīng)用融入 Spring Cloud 體系時(shí)就發(fā)現(xiàn)了許多問(wèn)題剃毒，也許未來(lái)的 Service Mesh 才是更合理的發(fā)展道路病袄。

該圖取自純潔的微笑公眾號(hào)

這是典型的 Spring Cloud 的使用方法:

Zuul 作為 Gateway搂赋，分發(fā)不同客戶(hù)端的請(qǐng)求到具體 Service。

Eureka 作為注冊(cè)中心益缠，完成了服務(wù)發(fā)現(xiàn)和服務(wù)注冊(cè)脑奠。

每個(gè) Service 包括 Gateway 都自帶了 Hystrix 提供的限流和熔斷功能。

Service 之間通過(guò) Feign 和 Ribbon 互相調(diào)用幅慌，F(xiàn)eign 實(shí)際上是屏蔽了 Service 對(duì) Eureka 的操作宋欺。

上文說(shuō)的一旦要融入異構(gòu)語(yǔ)言的 Service，那么服務(wù)注冊(cè)胰伍，服務(wù)發(fā)現(xiàn)齿诞，服務(wù)調(diào)用，熔斷和限流都需要自己處理骂租。

再有關(guān)于 Zuul 要多說(shuō)幾句祷杈，Spring Cloud 提供的 Zuul 對(duì) Netflix 版本的做了裁剪，去掉了動(dòng)態(tài)路由功能(Groovy 實(shí)現(xiàn))渗饮。

另外一點(diǎn)就是 Zuul 的性能一般但汞，由于采用同步編程模型，對(duì)于 IO 密集型等后臺(tái)處理時(shí)間長(zhǎng)的鏈路非常容易將 Servlet 的線(xiàn)程池占滿(mǎn)互站。

所以如果將 Zuul 與主要 Service 放置在同一臺(tái)物理機(jī)上特占，在流量大的情況下，Zuul 的資源消耗非常大云茸。

實(shí)際測(cè)試也發(fā)現(xiàn)經(jīng)過(guò) Zuul 與直接調(diào)用 Service 的性能損失在 30% 左右是目，并發(fā)壓力大時(shí)更為明顯。

現(xiàn)在 Spring Cloud Gateway 是 Pivotal 主推的标捺，支持異步編程模型懊纳，后續(xù)架構(gòu)優(yōu)化也許會(huì)采用，或是直接使用 Kong 這種基于 Nginx 的網(wǎng)關(guān)來(lái)提供性能亡容。

當(dāng)然同步模型也有優(yōu)點(diǎn)嗤疯，編碼更簡(jiǎn)單，后文將會(huì)提到使用 ThreadLocal 如何建立鏈路跟蹤闺兢。

架構(gòu)改造

經(jīng)過(guò)大半年的改造以及新需求的加入茂缚，單體服務(wù)被不斷拆分，最終形成了 10 余個(gè)微服務(wù)屋谭，并且搭建了 Spark 用于 BI脚囊。

初步形成兩大體系，微服務(wù)架構(gòu)的在線(xiàn)業(yè)務(wù)系統(tǒng)(OLTP) + Spark 大數(shù)據(jù)分析系統(tǒng)(OLAP)桐磁。

數(shù)據(jù)源從只有 MySQL 增加到了 ES 和 Hive悔耘。多數(shù)據(jù)源之間的數(shù)據(jù)同步也是值得一說(shuō)的話(huà)題，但內(nèi)容太多不在此文贅述我擂。

服務(wù)拆分我們采用直接割接的方式衬以，數(shù)據(jù)表也是整體遷移缓艳。因?yàn)閹状未蟾脑斓纳?jí)申請(qǐng)了停服，所以步驟相對(duì)簡(jiǎn)單看峻。

如果需要不停服升級(jí)阶淘，那么應(yīng)該采用先雙寫(xiě)再逐步切換的方式保證業(yè)務(wù)不受影響。

自動(dòng)化部署

與 CI 比起來(lái)互妓，持續(xù)交付(CD)實(shí)現(xiàn)更為復(fù)雜溪窒，在資源不足的情況我們尚未實(shí)現(xiàn) CD，只是實(shí)現(xiàn)執(zhí)行了自動(dòng)化部署车猬。

由于生產(chǎn)環(huán)境需要通過(guò)跳板機(jī)操作霉猛，所以我們通過(guò) Jenkins 生成 jar 包傳輸?shù)教鍣C(jī)尺锚，之后再通過(guò) Ansible 部署到集群珠闰。

簡(jiǎn)單粗暴的部署方式在小規(guī)模團(tuán)隊(duì)開(kāi)發(fā)時(shí)還是夠用的，只是需要在部署前保證測(cè)試(人工測(cè)試 + 自動(dòng)化測(cè)試)到位瘫辩。

鏈路跟蹤

開(kāi)源的全鏈路跟蹤很多伏嗜，比如 Spring Cloud Sleuth + Zipkin，國(guó)內(nèi)有美團(tuán)的 CAT 等等伐厌。

其目的就是當(dāng)一個(gè)請(qǐng)求經(jīng)過(guò)多個(gè)服務(wù)時(shí)承绸，可以通過(guò)一個(gè)固定值獲取整條請(qǐng)求鏈路的行為日志，基于此可以再進(jìn)行耗時(shí)分析等挣轨，衍生出一些性能診斷的功能军熏。

不過(guò)對(duì)于我們而言，首要目的就是 Trouble Shooting卷扮，出了問(wèn)題需要快速定位異常出現(xiàn)在什么服務(wù)荡澎，整個(gè)請(qǐng)求的鏈路是怎樣的。

為了讓解決方案輕量晤锹，我們?cè)谌罩局写蛴?RequestId 以及 TraceId 來(lái)標(biāo)記鏈路摩幔。

RequestId 在 Gateway 生成表示唯一的一次請(qǐng)求，TraceId 相當(dāng)于二級(jí)路徑鞭铆，一開(kāi)始與 RequestId 一樣或衡，但進(jìn)入線(xiàn)程池或者消息隊(duì)列后，TraceId 會(huì)增加標(biāo)記來(lái)標(biāo)識(shí)唯一條路徑车遂。

舉個(gè)例子封断，當(dāng)一次請(qǐng)求會(huì)向 MQ 發(fā)送一個(gè)消息，那么這個(gè)消息可能會(huì)被多個(gè)消費(fèi)者消費(fèi)舶担，此時(shí)每個(gè)消費(fèi)線(xiàn)程都會(huì)自己生成一個(gè) TraceId 來(lái)標(biāo)記消費(fèi)鏈路澄港。加入 TraceId 的目的就是為了避免只用 RequestId 過(guò)濾出太多日志。

實(shí)現(xiàn)如圖所示：

簡(jiǎn)單的說(shuō)柄沮，通過(guò) ThreadLocal 存放 APIRequestContext 串聯(lián)單服務(wù)內(nèi)的所有調(diào)用回梧。

當(dāng)跨服務(wù)調(diào)用時(shí)废岂，將 APIRequestContext 信息轉(zhuǎn)化為 Http Header，被調(diào)用方獲取到 Http Header 后再次構(gòu)建 APIRequestContext 放入 ThreadLocal狱意，重復(fù)循環(huán)保證 RequestId 和 TraceId 不丟失即可湖苞。

如果進(jìn)入 MQ，那么 APIRequestContext 信息轉(zhuǎn)化為 Message Header 即可(基于 RabbitMQ 實(shí)現(xiàn))详囤。

當(dāng)日志匯總到日志系統(tǒng)后财骨，如果出現(xiàn)問(wèn)題，只需要捕獲發(fā)生異常的 RequestId 或是 TraceId 即可進(jìn)行問(wèn)題定位藏姐。

經(jīng)過(guò)一年來(lái)的使用隆箩，基本可以滿(mǎn)足絕大多數(shù) Trouble Shooting 的場(chǎng)景，一般半小時(shí)內(nèi)即可定位到具體業(yè)務(wù)羔杨。

運(yùn)維監(jiān)控

在容器化之前捌臊，采用 Telegraf + InfluxDB + Grafana 的方案。Telegraf 作為探針收集 JVM兜材，System理澎，MySQL 等資源的信息，寫(xiě)入 InfluxDB曙寡，最終通過(guò) Grafana 做數(shù)據(jù)可視化糠爬。

Spring Boot Actuator 可以配合 Jolokia 暴露 JVM 的 Endpoint。整個(gè)方案零編碼举庶，只需要花時(shí)間配置执隧。

容器化時(shí)代

架構(gòu)改造

因?yàn)樵谧鑫⒎?wù)之初就計(jì)劃了容器化，所以架構(gòu)并未大動(dòng)户侥，只是每個(gè)服務(wù)都會(huì)建立一個(gè) Dockerfile 用于創(chuàng)建 docker image镀琉。

涉及變化的部分包括：

CI 中多了構(gòu)建 docker image 的步驟。

自動(dòng)化測(cè)試過(guò)程中將數(shù)據(jù)庫(kù)升級(jí)從應(yīng)用中剝離單獨(dú)做成 docker image添祸。

生產(chǎn)中用 Kubernetes 自帶的 Service 替代了 Eruka滚粟。

理由下文一一道來(lái)。

Spring Cloud&Kubernetes 融合

我們使用的是 Redhat 的 OpenShift刃泌，可以認(rèn)為是 Kubernetes 企業(yè)版凡壤，其本身就有 Service 的概念。一個(gè) Service 下有多個(gè) Pod耙替，Pod 內(nèi)即是一個(gè)可服務(wù)單元亚侠。

Service 之間互相調(diào)用時(shí) Kubernetes 會(huì)提供默認(rèn)的負(fù)載均衡控制，發(fā)起調(diào)用方只需要寫(xiě)被調(diào)用方的 ServiceId 即可俗扇。

這一點(diǎn)和 Spring Cloud Fegin 使用 Ribbon 提供的功能如出一轍硝烂。也就是說(shuō)服務(wù)治理可以通過(guò) Kubernetes 來(lái)解決，那么為什么要替換呢?

其實(shí)上文提到了铜幽，Spring Cloud 技術(shù)棧對(duì)于異構(gòu)語(yǔ)言的支持問(wèn)題滞谢，我們有許多 BFF(Backend for Frontend)是使用 Node.js 實(shí)現(xiàn)的串稀。

這些服務(wù)要想融合到 Spring Cloud 中，服務(wù)注冊(cè)狮杨，負(fù)載均衡母截，心跳檢查等等都要自己實(shí)現(xiàn)。

如果以后還有其他語(yǔ)言架構(gòu)的服務(wù)加入進(jìn)來(lái)橄教，這些輪子又要重造清寇。基于此類(lèi)原因綜合考量后护蝶，決定采用 OpenShift 所提供的網(wǎng)絡(luò)能力替換 Eruka华烟。

由于本地開(kāi)發(fā)和聯(lián)調(diào)過(guò)程中依然依賴(lài) Eruka，所以只在生產(chǎn)上通過(guò)配置參數(shù)來(lái)控制：

eureka.client.enabled 設(shè)置為 false持灰，停止各服務(wù)的 Eureka 注冊(cè)盔夜。

ribbon.eureka.enabled 設(shè)置為 false，讓 Ribbon 不從 Eureka 獲取服務(wù)列表搅方。

以服務(wù) foo 為例比吭，foo.ribbon.listofservers 設(shè)置為 http://foo:8080绽族，那么當(dāng)一個(gè)服務(wù)需要使用服務(wù) foo 的時(shí)候姨涡，就會(huì)直接調(diào)用到 http://foo:8080。

CI 的改造

CI 的改造主要是多了一部編譯 docker image 并打包到 Harbor 的過(guò)程吧慢，部署時(shí)會(huì)直接從 Harbor 拉取鏡像涛漂。另一個(gè)就是數(shù)據(jù)庫(kù)的升級(jí)工具。

之前我們使用 Flyway 作為數(shù)據(jù)庫(kù)升級(jí)工具检诗，當(dāng)應(yīng)用啟動(dòng)時(shí)自動(dòng)執(zhí)行 SQL 腳本匈仗。

隨著服務(wù)實(shí)例越來(lái)越多，一個(gè)服務(wù)的多個(gè)實(shí)例同時(shí)升級(jí)的情況也時(shí)有發(fā)生逢慌，雖然 Flyway 是通過(guò)數(shù)據(jù)庫(kù)鎖實(shí)現(xiàn)了升級(jí)過(guò)程不會(huì)有并發(fā)悠轩，但會(huì)導(dǎo)致被鎖服務(wù)啟動(dòng)時(shí)間變長(zhǎng)的問(wèn)題。

從實(shí)際升級(jí)過(guò)程來(lái)看攻泼，將可能發(fā)生的并發(fā)升級(jí)變?yōu)閱我贿M(jìn)程可能更靠譜火架。此外后期分庫(kù)分表的架構(gòu)也會(huì)使隨應(yīng)用啟動(dòng)自動(dòng)升級(jí)數(shù)據(jù)庫(kù)變的困難。

綜合考量忙菠，我們將升級(jí)任務(wù)做了拆分何鸡，每個(gè)服務(wù)都有自己的升級(jí)項(xiàng)目并會(huì)做容器化。

在使用時(shí)牛欢，作為 run once 的工具來(lái)使用骡男，即 docker run -rm 的方式。并且后續(xù)也支持了設(shè)定目標(biāo)版本的功能傍睹，在私有化項(xiàng)目的跨版本升級(jí)中起到了非常好的效果隔盛。

至于自動(dòng)部署犹菱，由于服務(wù)之間存在上下游關(guān)系，例如 Config吮炕，Eruka 等屬于基本服務(wù)被其他服務(wù)依賴(lài)已亥，部署也產(chǎn)生了先后順序±赐溃基于 Jenkins 做 Pipeline 可以很好的解決這個(gè)問(wèn)題虑椎。

其實(shí)做為一個(gè)開(kāi)發(fā)者，有一個(gè)學(xué)習(xí)的氛圍跟一個(gè)交流圈子特別重要俱笛，這里我推薦一個(gè)Java交流群730379855捆姜，不管你是小白還是大牛歡迎入駐，大家一起交流成長(zhǎng)迎膜。