軟件體系架構閱讀筆記十

微服務架構淺談（二）--團隊職能的劃分和去中心化治理

1.微服務架構團隊職能的劃分

傳統單體架構將系統分紅具備不一樣職責的層次，對應的項目管理也傾向於將大的團隊分紅不一樣的職能團隊，主要包括：用戶交互UI團隊、後臺業務邏輯處理團隊與數據存取ORM團隊、DBA團隊等。每一個團隊只對本身分層的職責負責，並對使用方提供組件服務質量保證。若是其中一個模塊化組件須要升級、更新，那麼這個變動會涉及不一樣的分層團隊，即便升級和變動的改變很小，也須要進行跨團隊溝通：需求階段須要跨團隊溝通產品功能，設計階段須要跨團隊溝通設計方案，開發階段須要跨團隊溝通具體的接口定義，測試階段須要溝通業務迴歸等事宜，甚至上線都須要跨團隊溝通應用的上線順序。可見在傳統的總體架構下，後期的維護成本很高，出現事故的風險很大。

根據康威定律，團隊的交流機制應該與架構設計機制相對應。所以，在微服務架構下，職能團隊的劃分方法是咱們首先要考慮的一個核心要素微服務架構按照業務的功能進行劃分，每一個單一的業務功能叫做一個服務，每一個服務對應一個獨立的職能團隊，團隊裏包含用戶交互UI設計師、後臺服務開發人員、DBA、運營和運維人員。

 

在傳統的總體架構中，軟件是有生命週期的，經歷需求分析、開發和測試，而後被交付給運維團隊，這時開發團隊將會解散，這是對軟件的一個「放手」。而在微服務架構中，提倡運維人員也是服務項目團隊的一員，倡導誰開發、誰維護，實施終生維護制度。

在業務服務的內部實現須要升級或者變動時，團隊內的各角色成員進行溝通便可，而不須要進行跨團隊溝通，這大大提升了溝通效率。只有服務之間的接口須要變動時才須要跨部門溝通，若是前期在服務之間的交互上定義了良好的接口，則接口變動的機率並不大，即便接口模式有變動，也能夠經過必定的設計模式和規範來解決。

2微服務的去中心化治理

筆者曾經在一個互聯網平臺上工做，平臺的決策者倡導建設API網關，全部外部服務和內部服務都由統一的API網關進行管理。在項目初期，中心化的API網關統一了全部API的入口，這看起來很規範，但從技術角度來看限制了API的多樣化。隨着業務的發展，API網關開始暴露問題，每一個用戶請求通過機房時只要有服務之間的交互，則都會從API網關進行路由，服務上量之後，因爲內部服務之間的交互都會疊加在API網關的調用上，因此在很大程度上放大了API網關的調用TPS，API網關很快就遇到了性能瓶頸。

這個案例是典型的微服務的反模式，微服務倡導去中心化的治理，不推薦每一個微服務都使用相同的標準和技術來開發和使用服務。在微服務架構下可使用C++開發一個服務，來對接Java開發的另一個服務，對於異構系統之間的交互標準，一般可使用工具來補償。開發者能夠開發共用的工具，並分享給異構系統的開發者使用，來解決異構系統不一致的問題，例如：Thrift遠程調用框架使用中間語言（IDL）來定義接口，中間語言是獨立於任何語言的，並提供了工具來生成中間語言，以及在中間語言與具體語言之間的代碼轉換。

微服務架構倡導去中心化的服務管理和治理，儘可能不設置中心化的管理服務，最差也須要在中心化的管理服務宕機時有替代方案和設計。在筆者工做的支付平臺服務化建設中，第1層SOA服務化採用Dubbo框架進行定製化，若是Dubbo服務化出現了大面積的崩潰，則服務化體系會切換到點對點的hessian遠程調用，這被稱爲服務化降級，降級後點對點的hessian遠程調用時沒有中心化節點，總體上符合微服務的原理。

 轉載博客地址：https://blog.csdn.net/kwame211/article/details/78015601