五阿哥架構演進之微服務架構
一、微服務由來
微服務不是被發明出來的,而是從現實世界中總結出來的一種趨勢或模式。
-SamNewman
多端技術促使了服務架構升級為微服務架構,而互聯網加速了微服務架構演進。
微服務架構更關注廣度(大方向)併兼顧重要細節,滿足現有需求同時能應對將來的變化。
二、微服務的發展
2.1、面向服務架構SOA與微服務的關係是什麼?
SOA在發展過程中,由於廠商添加了太多元素(很多是出於銷售原因),把面向服務的架構SOA搞的聲名狼藉,同時SOA本身模式上也存在一些問題。微服務社區的很多技術人員都具有大型機構整合服務經驗,他們深知僅僅SOA已經不能完全涵蓋服務經驗,再加上互聯網的發展,讓這些整合服務經驗傳遞出來,於是微服務倡導者拒絕繼續使用SOA標籤。但還是有不少人認為微服務是從SOA中發展而來的,或許面向服務是對的。
2.2、微服務架構是否需要不斷演進?
設計合理的服務是要對系統有足夠的認識,從模塊到服務邊界以及暴露的內容都需要很高的認知,並且還需要很多設計理論支撐。微服務架構提倡持續改變和演進系統,變化無法避免,擁抱變化才是王道。
-工具支持
-制定原則
-實踐
三、微服務模式
3.1、微服務架構的主要好處有哪些?
技術異構性
彈性
擴展
簡化部署
與組織結構相匹配
可組合性
對可替代性的優化
3.2、微服務怎麼衡量好壞?
(1)、松耦合。 修改一個服務不需要修改另一個服務,最小知識原則,基於介面設計,API技術無關性。
(2)、高內聚。把因相同原因而變化的東西聚合到一起,而把因不同原因而變化的東西分離
開來。
3.3、微服務粒度如何衡量?
不能以代碼行多少來衡量服務粒度。比如像Kotlin語言能使用很少的代碼完成其他語言相同的功能,還比如一個服務的代碼可能有多個依賴項,而每個依賴項又會有很多代碼,再比如有的領域對象本身很複雜,服務的本質不應該在過渡強調服務的大小服務粒度與團隊結構相匹配,如果代碼庫過大,一個團隊無法正常維護,即可僅一步查分。
3.4、服務與應用的關係?
服務和應用可以一對一,也可以一組服務集一個應用,服務集通常是一個獨
立的業務模塊。但如何選擇要看團隊組織,只要與團隊能力匹配即可。
3.5、微服務如何建模
建模是一種能力,是需要有專業知識加業務理解。參考《微服務設計》、《領域驅動設計》等書
四、微服務架構在五阿哥的演進4.1、工具化-架構/PE/開發
完善服務治理
依賴關係管理
介面設計平台
服務編排
更完善的監控
安全控制
4.2、制定微服務原則-架構
讓目標和大方向一致,比如:一致的介面和數據流
4.3、實踐,更細粒度的約束-開發
關注服務邊界和邊界內的事情,把服務做到合適。實踐出細粒度規則,做好服務的粒度及服務暴露的粒度需要比較高設計能力。
部分文檔摘自《微服務設計》,中國工信出版集團,人民郵電出版社,[英] 紐曼(Sam Newman) 著;崔力強,張駿 譯
作者系五阿哥架構部負責人:菏澤
推薦閱讀:
※《微服務設計》閱讀筆記(九)安全
※《Cloud Native Go》筆記(十五)結論
※《微服務設計》閱讀筆記(四)集成
※《微服務設計》閱讀筆記(八) 監控
※《微服務設計》閱讀筆記(十二完結篇)總結
TAG:微服務架構 |