文章目錄
-
- 前言
- 微服務的風格特點
-
- 1、元件化（Componentization ）與服務（Services）
- 2、圍繞業務功能的組織
- 3、産品不是項目
- 4、強化終端及弱化通道
- 5、分散治理
- 6、分散資料管理
- 7、基礎設施自動化
- 8、容錯性設計
- SpringBoot和SpringCloud與微服務之間的關系
前言
微服務是一種項目開發的設計思想。初期，我們往往将一個項目整體開發，整體部署。
這樣的好處是在項目部署階段是簡單的，但是随着項目的體量的不斷的增大，以及項目功能的複雜度越來越高，我們發現整體開發部署的風格已經不再适用了。例如：
牽一發而動全身，并不是我們想要的
。
微服務的誕生意在解決上述的問題，微服務的一個特點是
分而治之
，項目的規模大功能複雜，那麼我們就可以根據部分的業務子產品将其進行拆分小的獨立的服務。既解決了
牽一發而動全身，并不是我們想要的
的問題，又更好的實作了
業務子產品之間的低耦合，業務子產品内部的高内聚
。
微服務架構還有一個技術外的好處，它使整個系統的分工更加明确，責任更加清晰，每個人專心負責為其他人提供更好的服務。
微服務的風格特點
接下來，我将從以下幾個方面總結出微服務的風格特點。
1、元件化（Componentization ）與服務（Services）
了解過vue的朋友會知道，vue其實就是一個元件化程式設計，元件化程式設計的好處是我們可以
随時進行元件的拔插，以實作快速的更換項目子產品而且不會影響其他的子產品
。
微服務的一個特點就是将整體項目中的業務子產品進行元件化（微服務），我們将每一個服務稱之為元件而不是元件庫，
這是因為服務可以獨立部署，如果有一個服務發生了改變，那麼你隻需要重新部署那個改變的服務即可
。這聽起來更像是一種"拔插式"的操作。
因為微服務是獨立部署的，那麼很多接口排程就變成了遠端排程，遠端調用比進制内調用更消耗資源，是以遠端 API 需要粗粒度（coarser-grained），但這會比較難使用。如果你需要調整元件間的職責配置設定，當跨越程序邊界時，這樣做将會很難。
2、圍繞業務功能的組織
設計一個系統時，将人員劃分為 UI 團隊，中間件團隊，DBA 團隊，那麼相應地，軟體系統也就會自然地被劃分為 UI 界面，中間件系統，資料庫。如下圖：
對于微服務（microservice ）而言，根據微服務的劃分方法不同，它傾向圍繞業務功能的組織來分割服務。這些服務實作商業領域的軟體，包括使用者界面，持久化存儲，任何的外部協作。
這就導緻，負責一個服務（微服務）的團隊雖具有的技術将是所有的【使用者體驗（user-experience）、資料庫（database）和項目管理（project management）】。這對開發人員的要求提高了一個高度，我們可以通過一張圖來進一步的解釋。
3、産品不是項目
很多的開發團隊都傾向與向運維組織方傳遞一個完成的項目（軟體），然後解散建構軟體的團隊。但是對于微服務的支援者，這個是不被認可的。
正如亞馬遜開發管理者所提倡的理念“你建構，你運維（you build, you run it）”。産品的理念，跟業務能力聯系起來。不是着眼于完成一個項目（軟體），而是有一個持續的關系，是如何能夠幫助軟體及其使用者提升業務能力。
4、強化終端及弱化通道
微服務傾向于做如下的選擇：強化終端及弱化通道。微服務的應用緻力
低耦合和高内聚
：
采用單獨的業務邏輯
，表現的更像經典Unix意義上的過濾器一樣，
接受請求、處理業務邏輯、傳回響應
。它們更喜歡簡單的REST風格，而不是複雜的協定，如WS或者BPEL或者集中式架構。
所謂的"強化終端及弱化通道"，就是"低耦合，高内聚"的一種展現，因為本身服務（微服務）之間是通過遠端API（接口）進行通信的，我們更希望"高内聚"，使得接口的調用高呢更加的純粹——服務之間的通信。對應的業務盡可能的都是在獨立的服務（微服務）中完成。
在整體工風格中，元件在程序内執行，程序間的消息通信通常通過調用方法或者回調函數。從整體式風格到微服務架構最大的問題在于通信方式的變更。從記憶體内部原始的調用變成遠端調用，産生的大量的不可靠通信。是以，你需要把粗粒度的方法成更加細粒度的通信。
5、分散治理
集中治理的一種好處是在單一平台上進行标準化，有利于維護。但是我們更加傾向于采用适當的工具解決适當的問題。
當我們把整體式架構中的元件，拆分成不同的服務時，我們在建構它們時有更多的選擇，例如：對于一些實時性能要求高的業務子產品，那麼我就可以使用C++進行開發，…
分散治理有他的絕對好處——物盡其用。對于一個問題而言，我們可以使用能适合它的工具來解決它。
6、分散資料管理
在傳統的開發中，我們都是共用一個資料庫。但是到了微服務階段，我們更傾向于采用分散資料管理，所謂的分散資料庫觀管理其實就是
對于每一個服務（微服務）而言，其都有它自己的資料庫
，我們可以通過下圖進一步的了解單一資料管理與分散資料管理的差別與聯系。
對于分散資料關系，要求開發者對于整個項目的業務需求更深的了解。但是對于不同得我服務（微服務）之間肯定會有資料庫上述互動，例如：資料的同步、資料的一至性問題…。通常會通過
事務
來解決這個問題。
使用事務是因為它能夠幫助處理一至性問題，但對時間的消耗是嚴重的，這給跨服務操作帶來難題。分布式事務非常難以實施，是以
微服務架構強調服務間事務的協調
，并清楚的認識一緻性隻能是最終一緻性以及通過補償運算處理問題。
選擇處理不一緻問題對于開發團隊來說是新的挑戰，但是也是一個常見的業務實踐模式。
通常業務上允許一定的不一緻以滿足快速響應的需求
，但同時也采用一些恢複的程序來處理這種錯誤。
當業務上處理強一緻性消耗比處理錯誤的消耗少時，這種付出是值的的
。
7、基礎設施自動化
許多使用微服務架構的産品或者系統，它們的團隊擁有豐富的持續部署（CD）以及它的前任持續內建的經驗。團隊使用這種方式建構軟體緻使更廣泛的依賴基礎設施自動化技術。下圖說明這種建構的流程：
另一個方面，我們發現使用微服務的團隊更加依賴于基礎設施的自動化。對于整體架構的部署與微服務架構的部署，我們通過下圖進一步的了解。
8、容錯性設計
使用服務作為元件的一個結果在于應用需要有能容忍服務的故障的設計。任務服務可能因為供應商的不可靠而故障，用戶端需要盡可能的優化這種場景的響應。
跟整體構架相比，這是一個缺點，因為它帶來的額外的複雜性。這将讓微服務團隊時刻的想到服務故障的情況下使用者的體驗。
對于微服務而言，熔斷、服務降級、限流顯得格外的重要。
熔斷
當多次通路一個服務失敗時，應熔斷，所謂的熔斷就是标記該服務已停止工作，直接傳回錯誤
。直至該服務恢複正常後再重建立立連接配接。
服務降級
當下遊的非核心業務服務停止工作後，那麼上遊服務應該降級，以保證核心業務不中斷
。比如：網上超市商城訂單送出界面有一個推薦商品的功能，當推薦子產品挂了後，送出訂單功能不能一起挂掉，隻需要暫時關閉推薦功能即可。
限流
當服務挂掉後，上遊服務或者使用者一般會習慣性地重試通路。
當服務恢複正常，很可能因為瞬間網絡流量過大又立刻挂掉
。是以需要限流機制。
限流政策有很多，最簡單的比如當機關時間内請求數過多時，丢棄多餘的請求。另外，也可以考慮分區限流——僅拒絕來自出錯服務的請求。
例如：商品服務和訂單服務都需要通路促銷服務，商品服務由于代碼問題發起了大量請求，促銷服務則隻限制來自商品服務的請求，來自訂單服務的請求則正常響應。
上文參照Martin Fowler的：Microservices
SpringBoot和SpringCloud與微服務之間的關系
其實SpringBoot和微服務之間并沒有什麼直接的聯系，畢竟微服務隻是一種思想。
說到微服務，在Spring的生态中，不得不提SpringCloud。我們可以通過SpringBoot+SpringCloud搭建一個微服務項目。
因為SpringCloud是關注全局的服務治理架構
，正好可以管理多個SpringBoot項目（服務）進而實作微服務。
值得注意的是，Spring boot可以離開Spring Cloud獨立使用開發項目，但是Spring Cloud離不開Spring boot，屬于
依賴
的關系。
spring boot使用了
約定大于配置
的理念，很多內建方案已經幫你選擇好了，能不配置就不配置，Spring Cloud很大的一部分是基于Spring boot來實作。
Spring boot專注于快速、友善內建的單個個體，Spring Cloud是關注全局的服務治理架構
。
Spring boot 是 Spring 的一套快速配置腳手架，可以基于spring boot 快速開發單個微服務；Spring Cloud是一個基于Spring Boot實作的雲應用開發工具。
通過下圖，能夠進一步了解SpringBoot和SpringCloud與微服務之間的關系
每晚睡前聽你說晚安，是屬于我的，最簡單而持久的幸福…