微服務專欄地址

1. 簡介

思考認知是一個長久的過程，結合實際工作經驗與情況反覆思考、實踐、認證、改進、思考，如此往復。V1.0，入門淺顯認知。
整體目錄可查看左側大拇指下第二個按鈕。

2. 如何權衡微服務的利弊

思考微服務架構的利與弊，以及權衡

2.1 有什麼優勢

獨立開發、部署、維護
- 支持業務快速迭代
- 提升開發效率
- 減少溝通成本
基於分佈式架構，支持高性能、高可擴展性、高穩定性
- 可根據需求動態新增、減少服務數量以及使用資源實現高性能、高可擴展性
- 服務是通過一組相同功能的服務提供，有較好的容錯性
技術多樣性：
- 每個團隊的技術棧不限
- 提供技術樣性的同時也要避免因此帶來的“技術災難”

2.2 有什麼弊端

分佈式帶來的複雜性
運維的挑戰
日誌監控、性能監控的挑戰
測試的複雜性

2.3 如何權衡

沒有萬全法，見“企業應該在什麼時候開始考慮引入微服務”一小節思考

3. 企業應該在什麼時候開始考慮引入微服務

3.1 爲什麼要考慮引入微服務

核心原因：目前的單體應用或者SOA架構已無法滿足業務的快速增長帶來的需求，包括功能迭代效率、應用性能要求、穩定性要求。且隨着時間推移問題越來越明顯
追逐潮流？相信是有的，或者抱着一步到位的理想開始就上微服務，不考慮業務、團隊、公司現狀，想後續一步一步完善

3.2 微服務與單體在生產效率上有什麼關係

應用系統複雜度低時，單體架構生產效率高
應用系統複雜度較高時，微服務架構生產效率高
兩者會有交叉點
但是團隊的能力起着決定性作用

3.3 要考慮哪些因素

是否出現需要引入微服務的情況
是否能夠根據業務將應用拆解，並能夠組建微服務團隊
是否能保證選取的微服務架構實施技術或框架能夠解決絕大部分微服務必須要解決的技術點
- 選型的微服務框架或者技術是否已在業界得到證明以及廣泛的使用
- 保證框架能勝任微服務架構需要解決的點
- 保證資料的健全，遇到問題能夠快速的解決
選型的微服務框架是否有熟練使用以及瞭解、熟悉其原理的同學，一個團隊摸着石頭過河必然會很痛苦，效率也無法保證

4. 微服務的團隊該如何組建

4.1 康威法則

4.1.1 是什麼

Orgnizations which design systems x are constrainted to produce designs which are copies of the communication structures of these orgnizations.

設計系統的組織，其產生的架構設計等價於組織之間的溝通結構

4.1.2 有什麼用

指導怎麼構建微服務團隊

　　一個傳統的項目從需求調研到開發、實施、運維，需要各個不同職能的團隊參與進來，比如需求設計，UI 團隊，服務端數據團隊，數據庫團隊，測試團隊和運維團隊。採用這種團隊協作的方式時，一個很小的改動都需要涉及到跨團隊的溝通協作。
　　微服務的構建是有一個個根據業務劃分出來的小團隊來實現的，相比較於傳統的開發模式，有着麻雀雖小五臟俱全的特點。
　　微服務團隊需要的是一個全棧的、跨職能的團隊，需要涵蓋整個項目週期的所有階段所需要的技能，包括前後端開發、UI、數據庫設計、測試、部署、運維。

4.1.3 團隊的組織方式

4.1.4團隊的三要素：

DevOps能力
保持服務的持續演進
保持團隊和架構的對齊微服務的團隊對組織的要求

5. 企業應該在什麼時候開始考慮引入微服務

5.1 爲什麼要考慮引入微服務

核心原因：目前的單體應用或者SOA架構已無法滿足業務的快速增長帶來的需求，包括功能迭代效率、應用性能要求、穩定性要求。且隨着時間推移問題越來越明顯
追逐潮流？相信是有的，或者抱着一步到位的理想開始就上微服務，不考慮業務、團隊、公司現狀，想後續一步一步完善

5.2 微服務與單體在生產力有什麼關係

5.3 要考慮哪些因素

是否出現需要引入微服務的情況
是否能夠根據業務將應用拆解，並能夠組建微服務團隊
是否能保證選取的微服務架構實施技術或框架能夠解決絕大部分微服務必須要解決的技術點
選型的微服務框架或者技術是否已在業界得到證明以及廣泛的使用
保證框架能勝任微服務架構需要解決的點
保證資料的健全，遇到問題能夠快速的解決
選型的微服務框架是否有熟練使用以及瞭解、熟悉其原理的同學，一個團隊摸着石頭過河必然會很痛苦，效率也無法保證

6. 如何給出一個清晰簡潔的服務分層方式

基礎服務層：由多個基礎服務構成
聚合服務：有一個或者多個基礎服務組合而成

7. 如何實施微服務

如果你搞不定單塊應用，別指望微服務能夠拯救你！
按業務劃分團隊
要有做“產品”的態度
智能端點與啞管道
去中心化治理
去中心化管理數據
基礎設施自動化
容錯設計
演進式設計
參考單塊優先

二：對微服務架構的思考