在架構師對于一個大型系統架構的設計與實施的程序中，面對環境、資源、團隊等各種因素的影響，幾乎不會出現完全相同的架構設計，對于微服務架構而言更是如此，由于并沒有一個標準或正式的定義，每位架構師都根據自身理解與實際情況來進行設計，并在發展的程序中不斷演化與完善，經過多年的發展，Martin Flower在Microservies一文中，提煉出了微服務架構的九大特性，用于指導大家設計架構，
服務組件化
組件，是一個可以獨立更換和升級的單元，就像PC中的CPU、記憶體、顯卡、硬碟一樣，獨立且可以更換升級而不影響其他單元，
在微服務架構中，需要我們對服務組件化分解，服務，是一種行程外的組件，它通過HTTP等通信協議進行協作，而不是像傳統組件那樣以嵌入的方式協同作業，每一個服務都獨立開發、部署，可以有效避免一個服務的修改引起整個系統的重新部署，
打一個不恰當的比喻，如果我們的PC組件以服務的方式構建，那么只維護主板和一些必要外設之后，計算能力通過一組外部服務實作，我們只需要告訴PC從哪個地址來獲得計算能力，通過服務定義的計算介面來實作我們使用程序中的計算需求，從而實作CPU組件的服務化，這樣原本復雜的PC服務得到了輕量化的實作，我們甚至只需要更換服務地址就能升級PC的計算能力，
按業務組織團隊
當決定如何劃分微服務時，通常也意味著我們要開始對團隊進行重新規劃與組織，按以往的方式，我們往往會從技術的層面講團隊劃分為多個，比如DBA團隊、運維團隊、后端團隊、前端團隊、設計師團隊等，若我們繼續按這種方式組織團隊來實施微服務架構開發，當有一個服務出現問題需要更改時，可能是一個非常簡單的變動，比如對人物描述增加一個欄位，這需要從資料存盤開始考慮一直到設計和前端，雖然大家的修改都非常小，但這會引起跨團隊的時間耗費和預算審批，
在實施微服務架構時，需要采用不同的團隊分割方法，由于每一個微服務都是針對特定業務的寬堆疊或是全堆疊實作，既要負責資料的持久化存盤，又要負責用戶的介面定義等各種跨專業領域的職能，因此，面對大型專案的時候，對于微服務團隊的拆分更加建議按業務線的方式進行拆分，一方面可以有效減少服務內部修改所產生的內耗；另一方面，團隊邊界可以變得更為清晰，
做“產品”的態度
在實施微服務架構的團隊中，每個小團隊都應該以做產品的方式，對其產品的整個生命周期負責，而不是以專案的模式，以完成開發與交付并將成果交接給維護者為最終目標，
開發團隊通過了解服務在具體生成環境中的情況，可以增加他們對具體業務的理解，比如，很多時間，一些業務中發生的特殊或例外情況，很可能產品經理都并不知曉，但細心的開發者很容易通過生產環境發現這些特殊的潛在問題或需求，
所以，我們需要用做“產品”的態度來對待每一個微服務，持續關注服務的運作情況，并不斷分析以幫助用戶來改善業務功能，
智能端點與啞管道
在單體應用中，組件間直接通過函式呼叫的方式進行互動協作，而在微服務架構中，由于服務不在一個行程中，組件間的通信模式發生了改變，若僅僅將原本在行程內的方法呼叫改為RPC方式的呼叫，會導致微服務之間產生繁瑣的通信，使得系統表現更為糟糕，所有，我們需要更粗粒度的通信協議，
在微服務架構中，通常會使用以下兩種服務呼叫方式：
- 第一種，使用HTTP的RESTful API或輕量級的訊息發送協議，實作資訊傳遞與服務呼叫的觸發，
- 第二種，通過在輕量級訊息總線上傳遞訊息，類似RabbitMQ等一些提供可靠異步交換的中間件，
去中心化治理
當我們采用集中化的架構治理方案時，通常在技術平臺上都會制定統一的標準，但是每一種技術平臺都有其短板，這會導致在碰到短板時，不得不花費大力氣去解決，并且可能因為其底層原因解決得不是很好，最終成為系統的瓶頸，
在實施微服務架構時，通過采用輕量級的契約定義介面，使得我們對于服務本身的具體技術平臺不再那么敏感，這樣整個微服務架構系統中各個組件就能針對其不同的業務特點選擇不同的技術平臺，終于不會出現殺雞用牛刀或是殺牛用指甲鉗的尷尬處境了，
去中心化管理資料
我們在實施微服務架構時，都希望讓每一個服務來管理其自有的資料庫，這就是資料管理的去中心化，
在去中心化程序中，我們除了將原有資料庫中的存盤內容拆分到新的同平臺的其他資料庫實體中之外（如把原本存盤在MySQL中的表拆分后，存盤到多個不同的MySQL實體中），也可以將一些具有特殊結構或業務特性的資料存盤到一些其他技術的資料庫實體中（如把日志資訊存盤到MongoDB中或把用戶登錄資訊存盤到Redis中），
雖然資料管理的去中心化可以讓資料管理更加細致化，通過采用更適合的技術可讓資料存盤和性能達到最優，但是，由于資料存盤于不同的資料庫實體中后，資料一致性也成為微服務架構中亟待解決的問題之一，分布式事務本身的實作難度就非常大，所以在微服務架構中，我們更強調在各服務之間進行“無事務”的呼叫，而對于資料一致性，只要求資料在最后的處理狀態是一致的即可；若在程序中發現錯誤，通過補償機制來進行處理，使得錯誤資料能夠達到最終的一致性，
基礎設施自動化
近年來云技術服務與容器化技術的不斷成熟，運維基礎設施的作業變得越來越容易，但是，當我們實施微服務架構時，資料庫、應用程式的個頭雖然都變小了，但是因為拆分的原因，數量成倍增長，這使得運維人員需要關注的內容也成倍增長，并且操作性任務也會成倍增長，這些問題若沒有得到妥善解決，必將成為運維人員的噩夢，
所以，在微服務架構中，務必從一開始就構建起“持續交付”平臺來支持整個實施程序，該平臺需要兩大內容，缺一不可，
- 自動化測驗：每次部署前的強心劑，盡可能地獲得對正在運行的軟體的信心，
- 自動化部署：解放繁瑣枯燥的重復性操作以及對多環節的配置管理，
容錯設計
在單體應用中，一般不存在單個組件故障而其他部件還在運行的情況，通常是一掛全掛，而在微服務架構中，由于服務都運行在獨立的行程中，所以存在部分服務出現故障，而其他服務正常運行的情況，比如，當正常運作的服務B呼叫到故障服務A時，因故障服務A沒有回傳，執行緒掛起開始等待，直到超時才能釋放，而此時若觸發服務B呼叫服務A的請求來自服務C，而服務C頻繁呼叫服務B時，由于其依賴服務A，大量執行緒被掛起等待，最后導致服務C也不能正常服務，這時就會出現故障的蔓延，
所以，在微服務架構中，快速檢測出故障并盡可能地自動恢復服務是必須被設計和考慮的，通常，我們都希望在每個服務中心實作監控和日志記錄的組件，比如服務狀態、斷路器狀態、吞吐量、網路延遲等關鍵資料的儀表盤等，
演進式設計
通過上面的幾點特征，我們已經能夠體會到，要實施一個完美的微服務架構，需要考慮的設計與成本并不小，對于沒有足夠經驗的團隊來說，甚至要比單體應用付出更多的代價，
所以，在很多情況下，架構師都會以演進的方式進行系統的構建，在初期，以單體系統的方式來設計和實施，一方面系統體量初期并不會很大，構建和維護成本都不高，另一方面，初期的核心業務在后期通常也不會發生巨大的改變，隨著系統的發展或者業務的需要，在架構師會將一些經常變動或是有一定時間效應的內容進行微服務處理，并將原來在單體系統中多變的模塊逐步拆分出來，而穩定不太變化的模塊就形成一個核心微服務存在于整個架構之中，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/169964.html
標籤：其他