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

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"微服務是否適合小團隊是個見仁見智的問題。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"迴歸現象看本質，隨着業務複雜度的提高，單體應用越來越龐大，就好像一個類的代碼行越來越多，分而治之，切成多個類應該是更好的解決方法，所以一個龐大的單體應用分出多個小應用也更符合這種分治的思想。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當然微服務架構不應該是一個小團隊一開始就該考慮的問題，而是慢慢演化的結果，謹慎過度設計尤爲重要。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"公司的背景是提供SaaS服務，對於大客戶也會有定製開發以及私有化部署。經過2年不到的時間，技術架構經歷了從單體到微服務再到容器化的過程。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"單體應用時代","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"早期開發只有兩個人，考慮微服務之類的都是多餘。不過由於受前公司影響，最初就決定了前後端分離的路線，因爲不需要考慮SEO的問題，索性就做成了SPA單頁應用。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"多說一句，前後端分離也不一定就不能服務端渲染，例如電商系統或者一些匿名即可訪問的系統，加一層薄薄的View層，無論是php還是用Thymeleaf都是不錯的選擇。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"部署架構上，我們使用Nginx代理前端HTML資源，在接收請求時根據路徑反向代理到server的8080端口實現業務。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/83/83279f6433931ca5988d149dfeb1cea1.webp","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"接口定義","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"接口按照標準的Restful來定義，","attrs":{}}]},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"版本，統一跟在 /api/後面，例如 ","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"/api/v2","attrs":{}}],"attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"以資源爲中心，使用複數表述，例如","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"/api/contacts","attrs":{}}],"attrs":{}},{"type":"text","text":"，也可以嵌套，如","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"/api/groups/1/contacts/100","attrs":{}}],"attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"url中儘量不使用動詞，實踐中發現做到這一點真的比較難，每個研發人員的思路不一致，起的名字也千奇百怪，都需要在代碼Review中覆蓋。","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"動作支持，","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"POST / PUT / DELELE / GET","attrs":{}}],"attrs":{}},{"type":"text","text":" ，這裏有一個坑，PUT和PATCH都是更新，但是PUT是全量更新而PATCH是部分更新，前者如果傳入的字段是空（未傳也視爲空）那麼也會被更新到數據庫中。目前我們雖然是使用PUT但是忽略空字段和未傳字段，本質上是一種部分更新，這也帶來了一些問題，比如確有置空的業務需要特殊處理。","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"接口通過swagger生成文檔供前端同事使用。","attrs":{}}]}]}],"attrs":{}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"持續集成(CI)","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"團隊初始成員之前都有在大團隊共事的經歷，所以對於質量管控和流程管理都有一些共同的要求。因此在開發之初就引入了集成測試的體系，可以直接開發針對接口的測試用例，統一執行並計算覆蓋率。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一般來說代碼自動執行的都是單元測試(Unit Test)，我們之所以叫集成測試是因爲測試用例是針對API的，並且包含了數據庫的讀寫，MQ的操作等等，除了外部服務的依賴基本都是符合真實生產場景，相當於把Jmeter的事情直接在Java層面做掉了。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這在開發初期爲我們提供了非常大的便利性。但值得注意的是，由於數據庫以及其他資源的引入，數據準備以及數據清理時要考慮的問題就會更多，例如如何控制並行任務之間的測試數據互不影響等等。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"爲了讓這一套流程可以自動化的運作起來， 引入Jenkins也是理所當然的事情了。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/6d/6de89d817b51ed94dabfd863d3e41463.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"開發人員提交代碼進入gerrit中，Jenkins被觸發開始編譯代碼並執行集成測試，完成後生成測試報告，測試通過再由reviewer進行代碼review。在單體應用時代這樣的CI架構已經足夠好用，由於有集成測試的覆蓋，在保持API兼容性的前提下進行代碼重構都會變得更有信心。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"微服務時代","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"服務拆分原則","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從數據層面看，最簡單的方式就是看數據庫的表之間是否有比較少的關聯。例如最容易分離的一般來說都是用戶管理模塊。如果從領域驅動設計（DDD）看，其實一個服務就是一個或幾個相關聯的領域模型，通過少量數據冗餘劃清服務邊界。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"單個服務內通過領域服務完成多個領域對象協作。當然DDD比較複雜，要求領域對象設計上是充血模型而非貧血模型。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從實踐角度講，充血模型對於大部分開發人員來說難度非常高，什麼代碼應該屬於行爲，什麼屬於領域服務，很多時候非常考驗人員水平。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"服務拆分是一個大工程，往往需要幾個對業務以及數據最熟悉的人一起討論，甚至要考慮到團隊結構，最終的效果是服務邊界清晰， 沒有環形依賴和避免雙向依賴。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"框架選擇","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"由於之前的單體服務使用的是spring boot，所以框架自然而的選擇了spring cloud。其實個人認爲微服務框架不應該限制技術與語言，但生產實踐中發現無論dubbo還是spring cloud都具有侵入性，我們在將nodejs應用融入spring cloud體系時就發現了許多問題。也許未來的service mesh纔是更合理的發展道路。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/31/318b628dfc24cc2e18a2bb59b72f7c3d.webp","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"這是典型的Spring Cloud的使用方法","attrs":{}}]},{"type":"bulletedlist","content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"zuul作爲gateway，分發不同客戶端的請求到具體service","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"erueka作爲註冊中心，完成了服務發現和服務註冊","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"每個service包括gateway都自帶了Hystrix提供的限流和熔斷功能","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"service之間通過feign和ribbon互相調用，feign實際上是屏蔽了service對erueka的操作","attrs":{}}]}]}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"上文說的一旦要融入異構語言的service，那麼服務註冊，服務發現，服務調用，熔斷和限流都需要自己處理。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"再有關於zuul要多說幾句，Sprin Cloud提供的zuul對Netflix版本的做了裁剪，去掉了動態路由功能（Groovy實現），另外一點就是zuul的性能一般，由於採用同步編程模型，對於IO密集型等後臺處理時間長的鏈路非常容易將servlet的線程池佔滿，所以如果將zuul與主要service放置在同一臺物理機上，在流量大的情況下，zuul的資源消耗非常大。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"實際測試也發現經過zuul與直接調用service的性能損失在30%左右，併發壓力大時更爲明顯。現在spring cloud gateway是pivotal的主推了，支持異步編程模型，後續架構優化也許會採用，或是直接使用Kong這種基於nginx的網關來提供性能。當然同步模型也有優點，編碼更簡單，後文將會提到使用ThreadLocal如何建立鏈路跟蹤。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"架構改造","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"經過大半年的改造以及新需求的加入，單體服務被不斷拆分，最終形成了10餘個微服務，並且搭建了Spark用於BI。初步形成兩大體系，微服務架構的在線業務系統(OLTP) + Spark大數據分析系統(OLAP)。數據源從只有Mysql增加到了ES和Hive。多數據源之間的數據同步也是值得一說的話題，但內容太多不在此文贅述。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/38/3848e58d86e6843e0e4f7953e3cbb5b6.webp","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"自動化部署","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"與CI比起來，持續交付（CD）實現更爲複雜，在資源不足的情況我們尚未實現CD，只是實現執行了自動化部署。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"由於生產環境需要通過跳板機操作，所以我們通過Jenkins生成jar包傳輸到跳板機，之後再通過Ansible部署到集羣。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/4c/4c2ca48f87c49971aba46e4ca446bd31.png","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"簡單粗暴的部署方式在小規模團隊開發時還是夠用的，只是需要在部署前保證測試（人工測試 + 自動化測試）到位。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"鏈路跟蹤","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"開源的全鏈路跟蹤很多，比如","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"spring cloud sleuth + zipkin","attrs":{}}],"attrs":{}},{"type":"text","text":"，國內有美團的CAT等等。其目的就是當一個請求經過多個服務時，可以通過一個固定值獲取整條請求鏈路的行爲日誌，基於此可以再進行耗時分析等，衍生出一些性能診斷的功能。不過對於我們而言，首要目的就是trouble shooting，出了問題需要快速定位異常出現在什麼服務，整個請求的鏈路是怎樣的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"爲了讓解決方案輕量，我們在日誌中打印RequestId以及TraceId來標記鏈路。RequestId在gateway生成表示唯一一次請求，TraceId相當於二級路徑，一開始與RequestId一樣，但進入線程池或者消息隊列後，TraceId會增加標記來標識唯一條路徑。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"舉個例子，當一次請求會向MQ發送一個消息，那麼這個消息可能會被多個消費者消費，此時每個消費線程都會自己生成一個TraceId來標記消費鏈路。加入TraceId的目的就是爲了避免只用RequestId過濾出太多日誌。實現如圖所示，","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/83/83fbd0f192f6529f9a1116ec806f44be.webp","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"簡單的說，通過ThreadLocal存放APIRequestContext串聯單服務內的所有調用，當跨服務調用時，將APIRequestContext信息轉化爲Http Header，被調用方獲取到Http Header後再次構建APIRequestContext放入ThreadLocal，重複循環保證RequestId和TraceId不丟失即可。如果進入MQ，那麼APIRequestContext信息轉化爲Message Header即可（基於Rabbitmq實現）。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"當日志彙總到日誌系統後，如果出現問題，只需要捕獲發生異常的RequestId或是TraceId即可進行問題定位","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/3f/3fdd23ddb2b66febe9093bf8ca15b5ef.webp","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"運維監控","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在容器化之前，採用","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"telegraf + influxdb + grafana","attrs":{}}],"attrs":{}},{"type":"text","text":"的方案。telegraf作爲探針收集jvm，system，mysql等資源的信息，寫入influxdb，最終通過grafana做數據可視化。","attrs":{}},{"type":"codeinline","content":[{"type":"text","text":"spring boot actuator","attrs":{}}],"attrs":{}},{"type":"text","text":"可以配合jolokia暴露jvm的endpoint。整個方案零編碼，只需要花時間配置。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"容器化時代","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"架構改造","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"因爲在做微服務之初就計劃了容器化，所以架構並未大動，只是每個服務都會建立一個Dockerfile用於創建docker image","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/3c/3c7ebaa6b2a51282bde09a6ea574fb56.webp","alt":"圖片","title":null,"style":[{"key":"width","value":"75%"},{"key":"bordertype","value":"none"}],"href":null,"fromPaste":true,"pastePass":true}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"涉及變化的部分包括：","attrs":{}}]},{"type":"numberedlist","attrs":{"start":null,"normalizeStart":1},"content":[{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":1,"align":null,"origin":null},"content":[{"type":"text","text":"CI中多了構建docker image的步驟","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":2,"align":null,"origin":null},"content":[{"type":"text","text":"自動化測試過程中將數據庫升級從應用中剝離單獨做成docker image","attrs":{}}]}]},{"type":"listitem","attrs":{"listStyle":null},"content":[{"type":"paragraph","attrs":{"indent":0,"number":3,"align":null,"origin":null},"content":[{"type":"text","text":"生產中用k8s自帶的service替代了eruka","attrs":{}}]}]}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"理由下文一一道來。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"Spring Cloud與k8s的融合","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我們使用的是Redhat的Openshift，可以認爲是k8s企業版，其本身就有service的概念。一個service下有多個pod，pod內即是一個可服務單元。service之間互相調用時k8s會提供默認的負載均衡控制，發起調用方只需要寫被調用方的serviceId即可。這一點和spring cloud fegin使用ribbon提供的功能如出一轍。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"也就是說服務治理可以通過k8s來解決，那麼爲什麼要替換呢？其實上文提到了，Spring Cloud技術棧對於異構語言的支持問題，我們有許多BFF（Backend for Frontend）是使用nodejs實現的，這些服務要想融合到Spring Cloud中，服務註冊，負載均衡，心跳檢查等等都要自己實現。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果以後還有其他語言架構的服務加入進來，這些輪子又要重造。基於此類原因綜合考量後，決定採用Openshift所提供的網絡能力替換eruka。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"由於本地開發和聯調過程中依然依賴eruka，所以只在生產上通過配置參數來控制，","attrs":{}}]},{"type":"codeblock","attrs":{"lang":null},"content":[{"type":"text","text":"eureka.client.enabled` 設置爲 false，停止各服務的eureka註冊\n`ribbon.eureka.enabled` 設置爲 false，讓ribbon不從eureka獲取服務列表\n以服務foo爲例，`foo.ribbon.listofservers` 設置爲 `http://foo:8080`，那麼當一個服務需要使用服務foo的時候，就會直接調用到`http://foo:8080\n","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":3},"content":[{"type":"text","text":"CI的改造","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"CI的改造主要是多了一部編譯docker image並打包到Harbor的過程，部署時會直接從Harbor拉取鏡像。另一個就是數據庫的升級工具。之前我們使用flyway作爲數據庫升級工具，當應用啓動時自動執行SQL腳本。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"隨着服務實例越來越多，一個服務的多個實例同時升級的情況也時有發生，雖然flyway是通過數據庫鎖實現了升級過程不會有併發，但會導致被鎖服務啓動時間變長的問題。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從實際升級過程來看，將可能發生的併發升級變爲單一進程可能更靠譜。此外後期分庫分表的架構也會使隨應用啓動自動升級數據庫變的困難。綜合考量，我們將升級任務做了拆分，每個服務都有自己的升級項目並會做容器化。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在使用時，作爲run once的工具來使用，即docker run -rm的方式。並且後續也支持了設定目標版本的功能，在私有化項目的跨版本升級中起到了非常好的效果。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"至於自動部署，由於服務之間存在上下游關係，例如config，eureka等屬於基本服務被其他服務依賴，部署也產生了先後順序。基於Jenkins做pipeline可以很好的解決這個問題。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"小結","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"其實以上的每一點都可以深入的寫成一篇文章，微服務的架構演進涉及到開發，測試和運維，要求團隊內多工種緊密合作。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"分治是軟件行業解決大系統的不二法門，作爲小團隊我們並沒有盲目追新，而是在發展的過程通過服務化的方式解決問題。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"從另一方面我們也體會到了微服務對於人的要求，以及對於團隊的挑戰都比過去要高要大。未來仍需探索，演進仍在路上。","attrs":{}}]}]}