微服務應用
通常在單體系統中，開發者會在類、模塊、類別庫的層面來設計功能屬性，而在微服務應用中，開發者的目標則變成了可獨立部署的功能單元，而每個功能單元以一些復雜的方式進行互動，功能單元之間的相互協作則是通過一系列訊息協議來完成，而這些協議可能是點對點的也可能是異步的，每個功能單元共同合作起來形成了一個更加復雜的系統
微服務發展至今已并非新鮮事物，而其定義也非常容易理解，但它確實能夠顯著的降低復雜系統開發程序中的相互牽扯和沖突，且同時具備了軟體工程實踐倡導的【高內聚】【低耦合】，很顯然具備這樣特點的系統更容易維護、易擴展，通過這些手段完成為客戶持續交付價值的最終目的，這里的重點在于持續交付，而如果更高維度考慮，將其與商業行為結合，這個最終目的應該是為客戶快速的持續的交付價值，于是這里的重點便多了一個維度即快速的持續的
微服務特點
概念是非常容易懂的，稍微有幾年開發經驗的開發者一看便知道其中的意義，但到了實操層面具體該怎么做技術設計又無從下手，如果說微服務的概念告訴了我們它解決了什么問題，那么微服務的幾個特點【我更愿稱之為原則】告訴了我們應該如何做技術設計
高內聚 低耦合
內聚度時用來衡量某個模塊中的各個元素屬于一個整體的緊密程度的指標，耦合度則是衡量一個元素對另一個元素的內部運轉邏輯了解程度的指標，而在討論內聚和耦合的時候，單一職責原則便是一個很少的提升內聚的手段即：將那些因相同原因而修改的內容聚合到一起，將那些因不同原因而修改的內容進行拆分
單個微服務應該是高內聚的，它應該只負責應用的一個功能，同樣每個服務對其他服務的內部運轉邏輯知道的越少就越容易修改，而不需要讓其他服務跟著一起修改
場景實體
考慮一下出售股票的場景，大致需要如下4步處理
- 用戶創建一個訂單，用來出售其賬戶里某只股票的股份
- 賬戶中的這部分持倉就會被預留下來，確保相同的股份不可以被多次出售
- 提交訂單到市場上需要繳納印花稅
- 系統需要將這個訂單發送給對應的股票交易市場
如圖所示微服務設計，它是整個交易系統的一部分
從圖中可以看到，微服務的三大關鍵特點：
- 每個微服務只負責一個功能，這個功能可能是業務相關的功能，也可能是共用的技術功能，比如與第三方的集成
- 每個微服務都擁有自己的資料存盤，這是降低耦合非常關鍵的設計，各服務之間的資料訪問，僅可以通過服務提供的介面來訪問它們自己所不擁有的資料
- 微服務自己負責編排和協作(控制訊息和操作的執行順序來完成某些有用的功能)，既不是由連接微服務的訊息機制來完成的，也不是通過另外的軟體功能來完成的
除了以上的三大特點外，還有兩個基本特性：
- 每個微服務都可以獨立部署，如果做不到，那么到了部署階段微服務應用還是一個龐大的單體應用，而團隊不能僅僅考慮到coding的部分，還需要考慮部署、監控、診斷等一些列環節，如此微服務才能發揮其作用
- 每個微服務都是可代替的，每個微服務只具備一項功能，所以這很自然地限制了服務的大小，同時每個服務的職責或角色更加易于理解
微服務與SOA的區別
微服務與傳統的面向服務架構SOA有一個關鍵區別，微服務負責協調系統中的各個操作，而SOA型別的服務通常通過使用企業服務總線ESB或者更復雜的編排標準將應用本身與訊息和流程編排拆開，在SOA模型下，服務通常缺乏內聚度，因為業務邏輯會不斷地添加到服務總線上，而非服務本身
微服務與生俱來的優勢
- 可以針對每個問題選擇最合適的技術工具，無需多個服務死板的采用固有的技術和工具
- 自治和獨立部署意味著可以分別管理這些微服務所對應的資源需求，同時減少故障，不會因某個服務故障導致其他服務連鎖故障
- 自治性也使得開發者可以獨立的對這些服務進行開發、部署和擴容
5大核心原則
自治性、可恢復性、透明性、自動化和一致性
自治性
非常明確的是微服務是自治的，每個服務的操作和修改都是獨立于其他服務的，那么為了保證自治性，開發者需要將服務設計得松耦合、可獨立部署
松耦合
每個微服務通過明確定義的介面或者發布的事件訊息來與其他服務進行互動，這些互動需獨立于協作方的內部實作
可獨立部署
不同的服務通常由多個不同的團隊并行開發，因此獨立部署則成為快速交付價值的非常關鍵環節，也因此各服務之間相對完全獨立
自治性也是團隊文化，各個服務的責任和所有權委派給有責任交付商業價值的團隊，這是非常關鍵的管理決策，組織的設計會對系統設計產生影響，清晰的服務所有權有助于團隊基于他們本身所處的環境和目標迭代開發和做技術決策
可恢復性
微服務與生俱來的具備故障隔離的機制，如果開發者獨立的部署這些微服務，那么當應用或者基礎設施出現故障，故障只會影響到整個系統一部分功能，同樣部署功能的粒度越小、開發者越能更平緩的對系統進行變更
透明性
當故障發生時，開發者需要記得微服務應用是依賴于多個服務之間的互動及其表現的，而這些服務是由不同的團隊開發的，因此無論在什么時候系統都應該是透明的、可觀測的，如此更有利于發現問題診斷問題解決問題
自動化
通過開發大量的服務來緩解應用不斷變化所帶來的痛苦，看似有悖常理，事實上相對一單體系統，微服務確實是一種更加復雜的架構，通過采用自動化和在基礎設施內保持服務之間的一致性，開發者可以極大地降低因為這些額外的復雜性引入的管理成本，通過自動化也可以保證部署和系統運維程序中的正確性
微服務架構的流行與兩種趨勢是同時發生的，一種趨勢是DevOps技術的得到了主流接納，其中典型的就是**基礎設施即代碼(infrastructure-as-code)**技術；另一種趨勢是完全通過API進行編程的基礎設施環境(如AWS和Azure)的興起，三者同時發生并非巧合
一致性
以恰當的方式調整開發作業至關重要，開發者的目標應該是圍繞業務物體來組織服務和團隊，只有如此服務和團隊的內聚性才能更高
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/305643.html
標籤：其他