參考書籍《微服務設計》《微服務架構與實踐》

微服務的優點：

1.技術異構：不同的服務可以嘗試使用不同的技術（比如高併發的服務是不是可以嘗試使用nodejs 這種適合高併發的技術？針對高併發的資料操作，可以考慮使用記憶體資料庫類似的技術，而對於一般不怎麼用或者效能要求不高的服務則用常規的技術和資料庫即可） 2.彈性：一個服務故障不會導致級聯故障（通過將不同的例項執行在不同的機器上來降低功能完全不可用的概率） 3.擴充套件：單塊服務即使只有很小的一部分有效能問題，也需要對整個服務進行擴充套件。小的服務可以只對需要的服務進行擴充套件。比如開戶做活動時就只需要對開戶的服務進行橫向的部署，而購買產品的服務就不需要做任何的動作。 4.簡化部署：單塊應用即使只修改一行程式碼也需要部署整個應用，影響大風險高。小服務可以快速部署，快速回滾。 5.可組合性：更方便的重用已有功能（這個有利於減輕新應用開發工作量，比如手機團隊也賣基金，如果我們對於基金的資訊有個服務，那麼他們就不需要再次做各種介面，直接呼叫我們的服務就可以了） 6.小團隊的高效性：目前我們已經是小團隊作業了，已經具有了小團隊高效性的特點了 7.對可替代性的優化：一個小服務，如果想優化或者替代，很方便。如果是單個大應用，一般沒人敢動（鬼知道有多少影響）。  完成微服務設計或者改造需要做什麼： 1.增加測試程式碼以及引入持續整合平臺（如Jenkins）      即使不使用微服務架構，針對關鍵功能以及工具類引入單元測試也能夠有效的避免修改引入新的bug，可以減少人工測試的工作量，增加開發效率     （至於整合測試，針對我們目前的實際情況—和各種我們無法控制的平臺進行資料的互動，不建議使用過於複雜的自動的整合測試，用人工進行整合測試可能更適合我們）      目前的問題是我們使用的是私有的開發框架，是否方便以及有效的引入開源的單元測試框架。      介面開發要有明確的介面規範定義。      需要把持續部署對映到各個服務的測試環境（生產環境的部署怎麼處理？）      怎樣定製化映象（和docker 整合）      能否保持測試環境和生產環境的一致性（比如測試環境也有負載均衡） 2.log日誌平臺    需要對日誌進行規範，需要考慮如果一個請求路由到不同的服務上或者相同的服務不同的例項上之後怎樣能夠快速的檢索到使用者的呼叫鏈。同時如果出現問題，怎樣能夠快速的定位問題。 3.服務監控平臺    機器的執行情況，服務的執行情況，介面的訪問次數以及成功率，服務之間的呼叫關係，服務的部署架構圖等    預警/報警引數是否可配置？預警/報警方式都是什麼？ 4.架構安全性    (1) 如果一個服務出現異常，為了不影響其他服務，應該怎麼處理(比如如果所有的服務使用的是同一個連結池，那麼一個服務響應較慢，導致連結被佔完，那麼會影響整個應用的不可用)         每個微服務設計時都需要考慮我這個服務宕掉會發生什麼？會對其他服務或者整個應用造成什麼樣的影響。    (2) 對於上游終端訪問的許可權控制管理 以及 服務之間的訪問控制管理怎麼做 5.服務的劃分     鬆耦合：能夠獨立修改以及部署單個服務而不需要修改系統的其他部分     高內聚：相關行為聚在一起，改變     從功能考慮，而不是從資料考慮。    《領域驅動設計》 6. 服務之間的整合     哪些服務適合請求/響應 的模式，哪些服務適合基於事件的協作方式     如果使用事件的協同處理，怎樣進行流程的監控？需要如果一個一個業務流程處理失敗，其他業務流程怎樣處理？如果有事務的要求，事務怎樣處理？ 7.服務間怎樣進行靜態資料的共享   (1) 關係型資料庫？   (2) 資料copy 多份儲存到多個服務中？   (3) 統一的記憶體資料庫進行共享？ 8.整理報表需求    報表很可能要跨不同的服務進行資料的獲取。如果通過http 介面進行資料的獲取就會給系統帶來額外的不必要的壓力。    需要從資料庫層面進行考慮，把不同服務的資料推送到中央報表資料庫（只讀資料庫）    當然這個需要根據報表的時效性考慮不同的方法和技術。 9.服務間的身份驗證和授權    需要怎麼做呢？    如果是限定了ip，那麼對於服務的動態橫向擴充套件有限制。    如果每個服務/API都要做使用者驗證，那麼對於服務的效能又有一定的影響    提供給第三方或者一些很重要的API如果需要單獨的API金鑰，怎樣處理？     通過網段進行隔離？  如果需要選用第三方微服務平臺需要考察的內容： 1.部署（註冊，管理）：自動發現還是需要手動註冊？ 2.監控：掛載的服務，效能，日誌（使用什麼工具進行日誌的聚合以及問題的定位），應用的效能 3.安全：身份驗證和授權 4.流量：負載均衡 5.高可用：高可用部署方案 6.吞吐量：最大併發量，可以掛載的服務量 7.針對非同步請求（事件）的處理 8.針對協同工作，怎樣監控狀態？ 9.對於事務的解決方案：分散式事務 10.對於報表需求的處理（對於資料集中需求的處理） 11.身份認證的實現方式？是每個服務都進行單獨的驗證還是？是否有單點登入？ 12.服務之間的身份認證怎麼做？ 13.服務間訪問http連結池以及超時控制？斷路器？每個下游服務使用不同的連結池，這樣即使一個連結池用盡也不會影響其他服務的連結 14.分散式協調系統（服務的註冊和發現）是自己的演算法還是開源的工具？     這個比較重點，如果是自己的演算法，那麼可能會存在過多的隱藏的bug，而開源的工具大家都用，更有利。 15. 是否具有對服務進行健康檢查的能力 16.支援什麼樣的分散式事務（這個取決於業務需要什麼樣的事務） 17.綜合監控：機器狀態，服務狀態，介面狀態以及呼叫次數，介面響應時間，預警/報警引數設定以及預警/報警 方式 18.服務間的依賴管理