前言
前事不忘後事之師，本篇博客是在拜讀和學習了楊波的《微服務架構技術棧選型手冊》後結合自己的整理和思考。
https://www.infoq.cn/article/micro-service-technology-stack/
隨着IT技術發展和推進，傳統的單體應用程序模式已不滿足大多數企業IT平臺構建，尤其是大型互聯網網站或企業級應用。單體應用隨着項目持續集成，代碼庫越來越大，在系統複雜度、測試、代碼衝突解決、可擴展性、多環境支持、需求變更容易造成系統整體影響等方面面臨各種嚴峻挑戰。此時微服務架構應運而生。
微服務從2014的1.0技術元年開始，隨着微服務社區的推進，微服務技術體系生態產生極大變化，微服務進入2.0時代。微服務架構體系經過多年的大規模生產驗證，已成爲構建大型互聯網網站、大型企業級應用的首選分佈式技術架構。
相對於單體應用，微服務更具有優勢：
- 易於理解：微服務將應用按照功能分解爲獨立開發和部署的微型應用，每個服務與應用程序的其他微服務之間有一個很小且有限的契約。微服務更加專注目標，作爲一個功能模塊的單元，微服務更容易理解。
- 微服務易於測試：每個微服務都是獨立開發部署的微型應用，易於測試。在集成測試和驗收測試方面也更易於驗證。
- 較少遇到庫不兼容問題：每個微服務都有自己獨立的項目構建依賴項的集合，而這些集合不會與其他微服務共享。
- 微服務能夠獨立擴展：微服務之間獨立部署，因此指定微服務的內存和實例擴展不會影響整體應用其他微服務的內存和實例數量。
- 微服務可以獨立選擇不同的技術棧：微服務可以選擇不同的語言、平臺、框架和庫。特別是如果微服務採用HTTP協議這樣的跨平臺協議，實際上java微服務可以和C#、Python等編寫的微服務協作是完全合理的。
- 微服務更易於發佈：微服務是獨立部署的，因此不需要等待其他微服務部署就緒。同時隨着k8s、Dockers這樣的容器化、自動化部署工具的出現，讓微服務的發佈更加簡單。
微服務架構作爲分佈式架構，同樣面臨網絡延遲、多服務運維、分佈式複雜性等問題的挑戰，如何保證微服務的構建、發佈、運維管理，合理的微服務技術棧選型是重中之中。
選型準則
生產級
我們使用微服務架構是要解決實際業務場景和生產抗流量的，而不是做簡單的demo，如果選擇不慎可能出現生產級事故。因此，生產級（Production Ready）、可運維（Ops Ready）、可治理、技術成熟的微服務技術纔是我們的首選。
使用已經在多個一線互聯網或大型企業落地並經過生產挑戰的
我們應該儘量選擇使用已經在多個一線互聯網或大型企業落地並經過生產挑戰並且開源的，且在社區有良好口碑的技術棧。
開源社區活躍
社區活躍、stars數量越多、代碼和文檔更新頻率高的技術棧是優選選擇的，開源社區活躍可以直接反應技術的生命力。
結合項目實際情況
不是所有項目都適用於微服務架構體系，多餘研發團隊較少、應用日流量少的業務體量和企業應該慎重考慮是否使用微服務構建項目。微服務架構主要還是針對高併發、高日流量、研發團隊規模較大且有獨立的運維團隊這樣的大型業務平臺或團隊。同時針對團隊技術能力，選擇合適的微服務架構也是很有必要。
微服務基礎架構關鍵
微服務2.0架構核心模塊
微服務總體架構
微服務框架選型
微服務框架經過多年發展是一個比較成熟的領域，有比較多選擇，以下爲市場主流微服務架構對比：
| 功能點/微服務框架 | Spring Boot/Cloud | Dubbo/DubboXg | gRpc | Thirft | Motan |
| 功能點位 | 完整微服務框架方案 | 服務框架 | RPC | RPC | RPC |
| 是否支持REST | 是，基於Ribbon支持多種可插拔的序列化選擇 | 否 | 否 | 否 | 否 |
| 是否支持RPC | 否 | 是 | 是 | 是 | 是 |
| 是否支持多語言 | 是 | 否 | 是 | 是 | 否 |
| 典型案例 | Netflix | 阿里、噹噹 | 谷歌 | Sina | |
| 社區活躍 | 高 | 高 | 高 | 一般 | 一般 |
| 文檔豐富度 | 高 | 高 | 一般 | 一般 | 一般 |
Spring Boot/Cloud由於其Spring社區影響和Netflix的背書，以及其提供的完整一套微服務框架實現方案，目前可以認爲是基於java構建微服務的標準方案。其對於新興團隊或未形成自己微服務體系的團隊有較大吸引力。
Spring Boot/Cloud框架本身基於HTTP協議，是一種典型的RESTfull框架而不是RPC框架，序列化協議主要基於文本的JSON。
RESTfull天然支持跨語言平臺，任何支持HTTP協議的應用都可以接入調用，但是客戶端需要自己解析payload。