微服務架構實戰經驗系列【基本概念】

來自專欄 摳腳架構師

一、序言

軟體工程領域的前輩們早已告訴我們非常精闢的總結：由於軟體系統自身的複雜性，因此沒有一個放之四海皆準的軟體規範和架構標準。簡單概括就是：軟體沒有標準。言外之意是：規範和架構都是因業務和場景而異，而貫穿業務和架構，對內部系統架構具有前瞻性並起串聯組織架構作用的人，我們稱之為「業務系統架構師」。正是因為軟體的複雜性、沒有標準，所以才誕生了制定特定領域非通用標準的架構師職位。

上網一搜微服務，普天蓋地的文章和各種技術會議，這是對「微服務」這個名詞火爆程度的最佳見證。如果公司內部不搞一個微服務培訓，核心業務體系或平台架構不和微服務扯上關係，遇見同行都不好意思「打招呼」，一起吃個飯都覺得自己和別人不是一個時代的人。

那麼微服務到底是什麼？怎麼快速構建微服務架構？實戰中有哪些問題需要改進？......等等這一系列的問題都會在本文以及後續的文章中加以闡述，與君同饗「微服務」這頓饕餮大餐。

二、什麼是微服務

到底什麼是微服務？其實真的不太好說清楚。我所定義的微服務架構大致有下面這麼些特徵：

「四性」特徵

• 編程語言無關性
• 通信協議通用性
• 業務模塊獨立性
• 服務集成持續性

「四化「特徵

• 版本迭代敏捷化
• 日誌處理集中化
• 資源分配集約化
• 項目部署容器化

上述的內容表面上看似有點泛泛而談，但不乏乾貨，箇中奧妙需要讀者結合工作經驗慢慢領悟。或有概括不全之處，會結合實際情況再做補充說明。

三、SOA和微服務

說到SOA和微服務有什麼區別？針對這個命題，曾經就想單獨拎出來寫一篇文章，後來疲於應付瞭然無味的工作而耽擱了下來。重新撿拾起原來寫的一段文字，細細品味又是另一番領悟。

SOA和微服務都屬於服務化架構，都是軟體工程領域為了應對不斷增長的業務量而作出的架構抉擇，兩者天然符合分散式思想。

兩者在設計異構服務間通信策略上採取不通思路，我認為這也是兩者最大的區別。

1. SOA使用高度中心化的ESB（Enterprise Service Bus）來實現服務編排、協議轉換、消息映射、消息路由。異構系統一般不能直接通信，而是通過ESB作為中間層來實現間接消息通信。
2. 微服務不再強調重量級、集中式的ESB，而是默認去ESB。異構系統之間通信可以通過插件（比如Spring Cloud微服務生態圈的sidecar）作為中間層，最後完成異構系統整合。

必須強調一點，SOA架構使用ESB這個企業級服務通信中間層，其實是非常中心化和重量級的，一般使用消息中間件實現通信；而Spring Cloud微服務架構則在這一點上採用去中心化式的做法，每個非JVM異構服務都可以使用Spring Cloud生態系統提供的異構服務整合組件spring-cloud-netflix-sidecar來嵌入，一般使用應用層HTTP/HTTPS實現核心服務之間的通信，但有些諸如配置刷新等非核心內容也會通過rabbitmq等消息組件（Spring Cloud Bus）來實現。

SOA和微服務一脈相承，微服務作為SOA的最佳實踐方式已基本替代了傳統SOA架構。未來微服務也會慢慢地演進，微服務2.0 Service Mesh（服務網格）也逐步在國內技術圈流行起來。

四、權衡微服務利弊

個人感受，一切事物都存在利弊，可能只是場景、技術、時代、認知等諸多方面因素，使得在當時覺得某些事物是利大於弊，或者弊大於利。架構進化、架構選擇等脫離場景和技術背景都是扯淡，只有在立足業務和團隊技術積澱的基礎上選擇適當架構才是實戰派的正確做法和最終歸宿。

微服務有利有弊，這是正確對待微服務架構的態度。片面認為微服務不好，排斥微服務而不與大潮接軌，始終做井底之蛙是不對的；或者片面認為微服務很好，不假思索地對原有架構進行微服務化改造也是不宜之舉。

先說下微服務最明顯的幾處優點。

1. 服務化架構，提高代碼復用率（服務粒度降低，服務邊界和指責明確），同時改善架構可靠性，不需要每搭建一套系統就重寫一份不一定可靠的代碼，復用已有服務即可。
2. 異構化架構，包容各有所長編程語言異構系統，減少重複造輪子成本，取它人之長補己之短。
3. 微型化架構，項目組織方式可以以小團隊開發、維護、迭代、持續集成、持續交付等敏捷方式展開，加快產品迭代速度，同時也可在一定程度上提高整體代碼質量。

再提下使用微服務可能存在的問題。

1. 如果架構師不能夠考慮到公司自身團隊的技術水準，以及自身架構水準，而一味採用微服務，可能會產生小團隊之間協調困難，持續集成問題百出。
2. 對現有技術棧沒有深度思考，架構方式很可能導致服務之間調用出現巨大紕漏。說到底這個不是微服務本身問題，是組織「微服務」的架構師的責任。沒有及時與一線開發人員充分溝通而只憑網上幾篇文章和自己的無知就拼出一個所謂的「微服務框架」。
3. 服務拆分一定要注意服務的邊界和粒度，其中領域模型又是極為重要的，這點很能看出架構師之間的水平差距。服務拆的不好，導致服務邊界模糊，會出現服務互串，不利於開發、測試和運維。
4. 服務拆分很重要，但是比服務拆分更重要、更困難的是服務集成和服務編排，這一點更能夠看出架構師的水平。服務拆分後，服務之間需要通信，相比傳統做法的難度就上了一個層次，這其中就會暴露很多問題，導致持續集成成本陡增。

五、後記

本文只是《微服務架構實戰經驗系列》的第一篇文章，主要內容是相對系統地介紹些微服務經驗總結，不感興趣完全可以繞過去。後續的文章會慢慢地介紹基於Spring Cloud技術棧以及其它技術棧內容，這些內容都會基於作者的深度思考內容，將知識點串成知識面。不喜勿噴！