小團隊真的適合引入SpringCloud微服務嗎？

點擊上方“程序員大白”，選擇“星標”公眾號
重磅干貨，第一時間送達

微服務是否適合小團隊是個見仁見智的問題。

回歸現(xiàn)象看本質(zhì)，隨著業(yè)務復雜度的提高，單體應用越來越龐大，就好像一個類的代碼行越來越多，分而治之，切成多個類應該是更好的解決方法，所以一個龐大的單體應用分出多個小應用也更符合這種分治的思想。

當然微服務架構(gòu)不應該是一個小團隊一開始就該考慮的問題，而是慢慢演化的結(jié)果，謹慎過度設計尤為重要。

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

單體應用時代

早期開發(fā)只有兩個人，考慮微服務之類的都是多余。不過由于受前公司影響，最初就決定了前后端分離的路線，因為不需要考慮SEO的問題，索性就做成了SPA單頁應用。

多說一句，前后端分離也不一定就不能服務端渲染，例如電商系統(tǒng)或者一些匿名即可訪問的系統(tǒng)，加一層薄薄的View層，無論是php還是用Thymeleaf都是不錯的選擇。

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

接口定義

接口按照標準的Restful來定義，

• 版本，統(tǒng)一跟在 /api/后面，例如 /api/v2
• 以資源為中心，使用復數(shù)表述，例如/api/contacts，也可以嵌套，如/api/groups/1/contacts/100
• url中盡量不使用動詞，實踐中發(fā)現(xiàn)做到這一點真的比較難，每個研發(fā)人員的思路不一致，起的名字也千奇百怪，都需要在代碼Review中覆蓋。
• 動作支持，POST / PUT / DELELE / GET ，這里有一個坑，PUT和PATCH都是更新，但是PUT是全量更新而PATCH是部分更新，前者如果傳入的字段是空（未傳也視為空）那么也會被更新到數(shù)據(jù)庫中。目前我們雖然是使用PUT但是忽略空字段和未傳字段，本質(zhì)上是一種部分更新，這也帶來了一些問題，比如確有置空的業(yè)務需要特殊處理。
• 接口通過swagger生成文檔供前端同事使用。

持續(xù)集成(CI)

團隊初始成員之前都有在大團隊共事的經(jīng)歷，所以對于質(zhì)量管控和流程管理都有一些共同的要求。因此在開發(fā)之初就引入了集成測試的體系，可以直接開發(fā)針對接口的測試用例，統(tǒng)一執(zhí)行并計算覆蓋率。

一般來說代碼自動執(zhí)行的都是單元測試(Unit Test)，我們之所以叫集成測試是因為測試用例是針對API的，并且包含了數(shù)據(jù)庫的讀寫，MQ的操作等等，除了外部服務的依賴基本都是符合真實生產(chǎn)場景，相當于把Jmeter的事情直接在Java層面做掉了。

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

為了讓這一套流程可以自動化的運作起來， 引入Jenkins也是理所當然的事情了。

開發(fā)人員提交代碼進入gerrit中，Jenkins被觸發(fā)開始編譯代碼并執(zhí)行集成測試，完成后生成測試報告，測試通過再由reviewer進行代碼review。在單體應用時代這樣的CI架構(gòu)已經(jīng)足夠好用，由于有集成測試的覆蓋，在保持API兼容性的前提下進行代碼重構(gòu)都會變得更有信心。

微服務時代

服務拆分原則

從數(shù)據(jù)層面看，最簡單的方式就是看數(shù)據(jù)庫的表之間是否有比較少的關聯(lián)。例如最容易分離的一般來說都是用戶管理模塊。如果從領域驅(qū)動設計（DDD）看，其實一個服務就是一個或幾個相關聯(lián)的領域模型，通過少量數(shù)據(jù)冗余劃清服務邊界。

單個服務內(nèi)通過領域服務完成多個領域?qū)ο髤f(xié)作。當然DDD比較復雜，要求領域?qū)ο笤O計上是充血模型而非貧血模型。

從實踐角度講，充血模型對于大部分開發(fā)人員來說難度非常高，什么代碼應該屬于行為，什么屬于領域服務，很多時候非?？简炄藛T水平。

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

框架選擇

由于之前的單體服務使用的是spring boot，所以框架自然而的選擇了spring cloud。其實個人認為微服務框架不應該限制技術(shù)與語言，但生產(chǎn)實踐中發(fā)現(xiàn)無論dubbo還是spring cloud都具有侵入性，我們在將nodejs應用融入spring cloud體系時就發(fā)現(xiàn)了許多問題。也許未來的service mesh才是更合理的發(fā)展道路。

這是典型的Spring Cloud的使用方法，該圖取自純潔的微笑公眾號

• zuul作為gateway，分發(fā)不同客戶端的請求到具體service
• erueka作為注冊中心，完成了服務發(fā)現(xiàn)和服務注冊
• 每個service包括gateway都自帶了Hystrix提供的限流和熔斷功能
• service之間通過feign和ribbon互相調(diào)用，feign實際上是屏蔽了service對erueka的操作

上文說的一旦要融入異構(gòu)語言的service，那么服務注冊，服務發(fā)現(xiàn)，服務調(diào)用，熔斷和限流都需要自己處理。

再有關于zuul要多說幾句，Sprin Cloud提供的zuul對Netflix版本的做了裁剪，去掉了動態(tài)路由功能（Groovy實現(xiàn)），另外一點就是zuul的性能一般，由于采用同步編程模型，對于IO密集型等后臺處理時間長的鏈路非常容易將servlet的線程池占滿，所以如果將zuul與主要service放置在同一臺物理機上，在流量大的情況下，zuul的資源消耗非常大。

實際測試也發(fā)現(xiàn)經(jīng)過zuul與直接調(diào)用service的性能損失在30%左右，并發(fā)壓力大時更為明顯?，F(xiàn)在spring cloud gateway是pivotal的主推了，支持異步編程模型，后續(xù)架構(gòu)優(yōu)化也許會采用，或是直接使用Kong這種基于nginx的網(wǎng)關來提供性能。當然同步模型也有優(yōu)點，編碼更簡單，后文將會提到使用ThreadLocal如何建立鏈路跟蹤。

架構(gòu)改造

經(jīng)過大半年的改造以及新需求的加入，單體服務被不斷拆分，最終形成了10余個微服務，并且搭建了Spark用于BI。初步形成兩大體系，微服務架構(gòu)的在線業(yè)務系統(tǒng)(OLTP) + Spark大數(shù)據(jù)分析系統(tǒng)(OLAP)。數(shù)據(jù)源從只有Mysql增加到了ES和Hive。多數(shù)據(jù)源之間的數(shù)據(jù)同步也是值得一說的話題，但內(nèi)容太多不在此文贅述。

自動化部署

與CI比起來，持續(xù)交付（CD）實現(xiàn)更為復雜，在資源不足的情況我們尚未實現(xiàn)CD，只是實現(xiàn)執(zhí)行了自動化部署。

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

簡單粗暴的部署方式在小規(guī)模團隊開發(fā)時還是夠用的，只是需要在部署前保證測試（人工測試 + 自動化測試）到位。

鏈路跟蹤

開源的全鏈路跟蹤很多，比如spring cloud sleuth + zipkin，國內(nèi)有美團的CAT等等。其目的就是當一個請求經(jīng)過多個服務時，可以通過一個固定值獲取整條請求鏈路的行為日志，基于此可以再進行耗時分析等，衍生出一些性能診斷的功能。不過對于我們而言，首要目的就是trouble shooting，出了問題需要快速定位異常出現(xiàn)在什么服務，整個請求的鏈路是怎樣的。

為了讓解決方案輕量，我們在日志中打印RequestId以及TraceId來標記鏈路。RequestId在gateway生成表示唯一一次請求，TraceId相當于二級路徑，一開始與RequestId一樣，但進入線程池或者消息隊列后，TraceId會增加標記來標識唯一條路徑。

舉個例子，當一次請求會向MQ發(fā)送一個消息，那么這個消息可能會被多個消費者消費，此時每個消費線程都會自己生成一個TraceId來標記消費鏈路。加入TraceId的目的就是為了避免只用RequestId過濾出太多日志。實現(xiàn)如圖所示，

簡單的說，通過ThreadLocal存放APIRequestContext串聯(lián)單服務內(nèi)的所有調(diào)用，當跨服務調(diào)用時，將APIRequestContext信息轉(zhuǎn)化為Http Header，被調(diào)用方獲取到Http Header后再次構(gòu)建APIRequestContext放入ThreadLocal，重復循環(huán)保證RequestId和TraceId不丟失即可。如果進入MQ，那么APIRequestContext信息轉(zhuǎn)化為Message Header即可（基于Rabbitmq實現(xiàn)）。

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

運維監(jiān)控

在容器化之前，采用telegraf + influxdb + grafana的方案。telegraf作為探針收集jvm，system，mysql等資源的信息，寫入influxdb，最終通過grafana做數(shù)據(jù)可視化。spring boot actuator可以配合jolokia暴露jvm的endpoint。整個方案零編碼，只需要花時間配置。

容器化時代

架構(gòu)改造

因為在做微服務之初就計劃了容器化，所以架構(gòu)并未大動，只是每個服務都會建立一個Dockerfile用于創(chuàng)建docker image

涉及變化的部分包括：

1. CI中多了構(gòu)建docker image的步驟
2. 自動化測試過程中將數(shù)據(jù)庫升級從應用中剝離單獨做成docker image
3. 生產(chǎn)中用k8s自帶的service替代了eruka

理由下文一一道來。

Spring Cloud與k8s的融合

我們使用的是Redhat的Openshift，可以認為是k8s企業(yè)版，其本身就有service的概念。一個service下有多個pod，pod內(nèi)即是一個可服務單元。service之間互相調(diào)用時k8s會提供默認的負載均衡控制，發(fā)起調(diào)用方只需要寫被調(diào)用方的serviceId即可。這一點和spring cloud fegin使用ribbon提供的功能如出一轍。

也就是說服務治理可以通過k8s來解決，那么為什么要替換呢？其實上文提到了，Spring Cloud技術(shù)棧對于異構(gòu)語言的支持問題，我們有許多BFF（Backend for Frontend）是使用nodejs實現(xiàn)的，這些服務要想融合到Spring Cloud中，服務注冊，負載均衡，心跳檢查等等都要自己實現(xiàn)。

如果以后還有其他語言架構(gòu)的服務加入進來，這些輪子又要重造?；诖祟愒蚓C合考量后，決定采用Openshift所提供的網(wǎng)絡能力替換eruka。

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

eureka.client.enabled 設置為 false，停止各服務的eureka注冊
ribbon.eureka.enabled 設置為 false，讓ribbon不從eureka獲取服務列表
以服務foo為例，foo.ribbon.listofservers 設置為 http://foo:8080，那么當一個服務需要使用服務foo的時候，就會直接調(diào)用到http://foo:8080

CI的改造

CI的改造主要是多了一部編譯docker image并打包到Harbor的過程，部署時會直接從Harbor拉取鏡像。另一個就是數(shù)據(jù)庫的升級工具。之前我們使用flyway作為數(shù)據(jù)庫升級工具，當應用啟動時自動執(zhí)行SQL腳本。

隨著服務實例越來越多，一個服務的多個實例同時升級的情況也時有發(fā)生，雖然flyway是通過數(shù)據(jù)庫鎖實現(xiàn)了升級過程不會有并發(fā)，但會導致被鎖服務啟動時間變長的問題。

從實際升級過程來看，將可能發(fā)生的并發(fā)升級變?yōu)閱我贿M程可能更靠譜。此外后期分庫分表的架構(gòu)也會使隨應用啟動自動升級數(shù)據(jù)庫變的困難。綜合考量，我們將升級任務做了拆分，每個服務都有自己的升級項目并會做容器化。

在使用時，作為run once的工具來使用，即docker run -rm的方式。并且后續(xù)也支持了設定目標版本的功能，在私有化項目的跨版本升級中起到了非常好的效果。

至于自動部署，由于服務之間存在上下游關系，例如config，eruka等屬于基本服務被其他服務依賴，部署也產(chǎn)生了先后順序?；贘enkins做pipeline可以很好的解決這個問題。

小結(jié)

其實以上的每一點都可以深入的寫成一篇文章，微服務的架構(gòu)演進涉及到開發(fā)，測試和運維，要求團隊內(nèi)多工種緊密合作。

分治是軟件行業(yè)解決大系統(tǒng)的不二法門，作為小團隊我們并沒有盲目追新，而是在發(fā)展的過程通過服務化的方式解決問題。

從另一方面我們也體會到了微服務對于人的要求，以及對于團隊的挑戰(zhàn)都比過去要高要大。未來仍需探索，演進仍在路上。

推薦閱讀
國產(chǎn)小眾瀏覽器因屏蔽視頻廣告，被索賠100萬（后續(xù)）
年輕人“不講武德”：因看黃片上癮，把網(wǎng)站和786名女主播起訴了
中國聯(lián)通官網(wǎng)被發(fā)現(xiàn)含木馬腳本，可向用戶推廣色情APP
張一鳴：每個逆襲的年輕人，都具備的底層能力

關于程序員大白

程序員大白是一群哈工大，東北大學，西湖大學和上海交通大學的碩士博士運營維護的號，大家樂于分享高質(zhì)量文章，喜歡總結(jié)知識，歡迎關注[程序員大白]，大家一起學習進步！