作者：Dean
來源：deanwangpro.com/2019/02/18/road-of-microservice
微服務是否適合小團隊是個見仁見智的問題，
回歸現象看本質，隨著業務復雜度的提高，單體應用越來越龐大，就好像一個類的代碼行越來越多，分而治之，切成多個類應該是更好的解決方法，所以一個龐大的單體應用分出多個小應用也更符合這種分治的思想，
當然微服務架構不應該是一個小團隊一開始就該考慮的問題，而是慢慢演化的結果，謹慎過度設計尤為重要，
公司的背景是提供SaaS服務，對于大客戶也會有定制開發以及私有化部署，經過2年不到的時間，技術架構經歷了從單體到微服務再到容器化的程序，
單體應用時代
早期開發只有兩個人，考慮微服務之類的都是多余，不過由于受前公司影響，最初就決定了前后端分離的路線，因為不需要考慮SEO的問題，索性就做成了SPA單頁應用，
多說一句，前后端分離也不一定就不能服務端渲染，例如電商系統或者一些匿名即可訪問的系統，加一層薄薄的View層，無論是php還是用Thymeleaf都是不錯的選擇，
部署架構上，我們使用Nginx代理前端HTML資源，在接收請求時根據路徑反向代理到server的8080埠實作業務，
介面定義
介面按照標準的Restful來定義，
- 版本，統一跟在 /api/后面，例如
/api/v2 - 以資源為中心，使用復數表述，例如
/api/contacts，也可以嵌套，如/api/groups/1/contacts/100 - url中盡量不使用動詞，實踐中發現做到這一點真的比較難，每個研發人員的思路不一致，起的名字也千奇百怪，都需要在代碼Review中覆寫，
- 動作支持，
POST / PUT / DELELE / GET，這里有一個坑，PUT和PATCH都是更新，但是PUT是全量更新而PATCH是部分更新，前者如果傳入的欄位是空（未傳也視為空）那么也會被更新到資料庫中，目前我們雖然是使用PUT但是忽略空欄位和未傳欄位，本質上是一種部分更新，這也帶來了一些問題，比如確有置空的業務需要特殊處理， - 介面通過swagger生成檔案供前端同事使用，
持續集成(CI)
團隊初始成員之前都有在大團隊共事的經歷，所以對于質量管控和流程管理都有一些共同的要求，因此在開發之初就引入了集成測驗的體系，可以直接開發針對介面的測驗用例，統一執行并計算覆寫率，
一般來說代碼自動執行的都是單元測驗(Unit Test)，我們之所以叫集成測驗是因為測驗用例是針對API的，并且包含了資料庫的讀寫，MQ的操作等等，除了外部服務的依賴基本都是符合真實生產場景，相當于把Jmeter的事情直接在Java層面做掉了，
這在開發初期為我們提供了非常大的便利性，但值得注意的是，由于資料庫以及其他資源的引入，資料準備以及資料清理時要考慮的問題就會更多，例如如何控制并行任務之間的測驗資料互不影響等等，
為了讓這一套流程可以自動化的運作起來， 引入Jenkins也是理所當然的事情了，
開發人員提交代碼進入gerrit中，Jenkins被觸發開始編譯代碼并執行集成測驗，完成后生成測驗報告，測驗通過再由reviewer進行代碼review，在單體應用時代這樣的CI架構已經足夠好用，由于有集成測驗的覆寫，在保持API兼容性的前提下進行代碼重構都會變得更有信心，
微服務時代
服務拆分原則
從資料層面看，最簡單的方式就是看資料庫的表之間是否有比較少的關聯，例如最容易分離的一般來說都是用戶管理模塊，如果從領域驅動設計（DDD）看，其實一個服務就是一個或幾個相關聯的領域模型，通過少量資料冗余劃清服務邊界，
單個服務內通過領域服務完成多個領域物件協作，當然DDD比較復雜，要求領域物件設計上是充血模型而非貧血模型，
從實踐角度講，充血模型對于大部分開發人員來說難度非常高，什么代碼應該屬于行為，什么屬于領域服務，很多時候非常考驗人員水平，
服務拆分是一個大工程，往往需要幾個對業務以及資料最熟悉的人一起討論，甚至要考慮到團隊結構，最終的效果是服務邊界清晰， 沒有環形依賴和避免雙向依賴，
框架選擇
由于之前的單體服務使用的是spring boot，所以框架自然而的選擇了spring cloud，其實個人認為微服務框架不應該限制技術與語言，但生產實踐中發現無論dubbo還是spring cloud都具有侵入性，我們在將nodejs應用融入spring cloud體系時就發現了許多問題，也許未來的service mesh才是更合理的發展道路，
這是典型的Spring Cloud的使用方法：
- zuul作為gateway，分發不同客戶端的請求到具體service
- erueka作為注冊中心，完成了服務發現和服務注冊
- 每個service包括gateway都自帶了Hystrix提供的限流和熔斷功能
- service之間通過feign和ribbon互相呼叫，feign實際上是屏蔽了service對erueka的操作
上文說的一旦要融入異構語言的service，那么服務注冊，服務發現，服務呼叫，熔斷和限流都需要自己處理，
再有關于zuul要多說幾句，Sprin Cloud提供的zuul對Netflix版本的做了裁剪，去掉了動態路由功能（Groovy實作），另外一點就是zuul的性能一般，由于采用同步編程模型，對于IO密集型等后臺處理時間長的鏈路非常容易將servlet的執行緒池占滿，所以如果將zuul與主要service放置在同一臺物理機上，在流量大的情況下，zuul的資源消耗非常大，
實際測驗也發現經過zuul與直接呼叫service的性能損失在30%左右，并發壓力大時更為明顯，現在spring cloud gateway是pivotal的主推了，支持異步編程模型，后續架構優化也許會采用，或是直接使用Kong這種基于nginx的網關來提供性能，當然同步模型也有優點，編碼更簡單，后文將會提到使用ThreadLocal如何建立鏈路跟蹤，
架構改造
經過大半年的改造以及新需求的加入，單體服務被不斷拆分，最終形成了10余個微服務，并且搭建了Spark用于BI，初步形成兩大體系，微服務架構的在線業務系統(OLTP) + Spark大資料分析系統(OLAP)，資料源從只有Mysql增加到了ES和Hive，多資料源之間的資料同步也是值得一說的話題，但內容太多不在此文贅述，
自動化部署
與CI比起來，持續交付（CD）實作更為復雜，在資源不足的情況我們尚未實作CD，只是實作執行了自動化部署，
由于生產環境需要通過跳板機操作，所以我們通過Jenkins生成jar包傳輸到跳板機，之后再通過Ansible部署到集群，
簡單粗暴的部署方式在小規模團隊開發時還是夠用的，只是需要在部署前保證測驗（人工測驗 + 自動化測驗）到位，
鏈路跟蹤
開源的全鏈路跟蹤很多，比如spring cloud sleuth + zipkin，國內有美團的CAT等等，其目的就是當一個請求經過多個服務時，可以通過一個固定值獲取整條請求鏈路的行為日志，基于此可以再進行耗時分析等，衍生出一些性能診斷的功能，不過對于我們而言，首要目的就是trouble shooting，出了問題需要快速定位例外出現在什么服務，整個請求的鏈路是怎樣的，
為了讓解決方案輕量，我們在日志中列印RequestId以及TraceId來標記鏈路，RequestId在gateway生成表示唯一一次請求，TraceId相當于二級路徑，一開始與RequestId一樣，但進入執行緒池或者訊息佇列后，TraceId會增加標記來標識唯一條路徑，
舉個例子，當一次請求會向MQ發送一個訊息，那么這個訊息可能會被多個消費者消費，此時每個消費執行緒都會自己生成一個TraceId來標記消費鏈路，加入TraceId的目的就是為了避免只用RequestId過濾出太多日志，實作如圖所示，
簡單的說，通過ThreadLocal存放APIRequestContext串聯單服務內的所有呼叫，當跨服務呼叫時，將APIRequestContext資訊轉化為Http Header，被呼叫方獲取到Http Header后再次構建APIRequestContext放入ThreadLocal，重復回圈保證RequestId和TraceId不丟失即可，如果進入MQ，那么APIRequestContext資訊轉化為Message Header即可（基于Rabbitmq實作），
當日志匯總到日志系統后，如果出現問題，只需要捕獲發生例外的RequestId或是TraceId即可進行問題定位
運維監控
在容器化之前，采用telegraf + influxdb + grafana的方案，telegraf作為探針收集jvm，system，mysql等資源的資訊，寫入influxdb，最終通過grafana做資料可視化，spring boot actuator可以配合jolokia暴露jvm的endpoint，整個方案零編碼，只需要花時間配置，
容器化時代
架構改造
因為在做微服務之初就計劃了容器化，所以架構并未大動，只是每個服務都會建立一個Dockerfile用于創建docker image
涉及變化的部分包括：
- CI中多了構建docker image的步驟
- 自動化測驗程序中將資料庫升級從應用中剝離單獨做成docker image
- 生產中用k8s自帶的service替代了eruka
理由下文一一道來，
Spring Cloud與k8s的融合
我們使用的是Redhat的Openshift，可以認為是k8s企業版，其本身就有service的概念，一個service下有多個pod，pod內即是一個可服務單元，service之間互相呼叫時k8s會提供默認的負載均衡控制，發起呼叫方只需要寫被呼叫方的serviceId即可，這一點和spring cloud fegin使用ribbon提供的功能如出一轍，
也就是說服務治理可以通過k8s來解決，那么為什么要替換呢？其實上文提到了，Spring Cloud技術堆疊對于異構語言的支持問題，我們有許多BFF（Backend for Frontend）是使用nodejs實作的，這些服務要想融合到Spring Cloud中，服務注冊，負載均衡，心跳檢查等等都要自己實作，
如果以后還有其他語言架構的服務加入進來，這些輪子又要重造，基于此類原因綜合考量后，決定采用Openshift所提供的網路能力替換eruka，
由于本地開發和聯調程序中依然依賴eruka，所以只在生產上通過配置引數來控制，
eureka.client.enabled` 設定為 false，停止各服務的eureka注冊
`ribbon.eureka.enabled` 設定為 false，讓ribbon不從eureka獲取服務串列
以服務foo為例，`foo.ribbon.listofservers` 設定為 `http://foo:8080`，那么當一個服務需要使用服務foo的時候，就會直接呼叫到`http://foo:8080
CI的改造
CI的改造主要是多了一部編譯docker image并打包到Harbor的程序，部署時會直接從Harbor拉取鏡像，另一個就是資料庫的升級工具，之前我們使用flyway作為資料庫升級工具，當應用啟動時自動執行SQL腳本，
隨著服務實體越來越多，一個服務的多個實體同時升級的情況也時有發生，雖然flyway是通過資料庫鎖實作了升級程序不會有并發，但會導致被鎖服務啟動時間變長的問題，
從實際升級程序來看，將可能發生的并發升級變為單一行程可能更靠譜，此外后期分庫分表的架構也會使隨應用啟動自動升級資料庫變的困難，綜合考量，我們將升級任務做了拆分，每個服務都有自己的升級專案并會做容器化，
在使用時，作為run once的工具來使用，即docker run -rm的方式，并且后續也支持了設定目標版本的功能，在私有化專案的跨版本升級中起到了非常好的效果，
至于自動部署，由于服務之間存在上下游關系，例如config，eruka等屬于基本服務被其他服務依賴，部署也產生了先后順序，基于Jenkins做pipeline可以很好的解決這個問題，
小結
其實以上的每一點都可以深入的寫成一篇文章，微服務的架構演進涉及到開發，測驗和運維，要求團隊內多工種緊密合作，
分治是軟體行業解決大系統的不二法門，作為小團隊我們并沒有盲目追新，而是在發展的程序通過服務化的方式解決問題，
從另一方面我們也體會到了微服務對于人的要求，以及對于團隊的挑戰都比過去要高要大，未來仍需探索，演進仍在路上，
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2021最新版)
2.終于靠開源專案弄到 IntelliJ IDEA 激活碼了，真香！
3.阿里 Mock 工具正式開源，干掉市面上所有 Mock 工具！
4.Spring Cloud 2020.0.0 正式發布，全新顛覆性版本！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/289000.html
標籤：其他