子產品化設計原則

１．高内聚低耦合原則：

• 確定每個子產品隻完成系統要求的獨立子功能；
• 子產品與子產品間的聯系最少且接口簡單；

２．降低子產品間耦合度：

• 越底層的子產品，應該越穩定，越抽象，越具有高複用度；
• 減少依賴，避免子產品依賴不穩定的子產品；
• 提升子產品的複用度，自完備性有時候要優于代碼複用；
• 每個子產品隻做好一件事情，減少Common的比例；

３．依賴倒置：

• 高層子產品不應該依賴低層子產品，兩者都應該依賴其抽象；
• 抽象不應該依賴細節，細節應該依賴抽象；
• 采用擴充卡模式适配各種雲平台，資料庫等，而不強依賴某種雲平台和資料庫;

設計模式６大原則（SOLID）

1.單一原則（Single Responsibility Principle）：

• 一個類或者一個方法隻負責一項職責，盡量做到類的隻有一個行為原因引起變化；
• 業務對象（BO business object）、業務邏輯（BL business logic）拆分；

2.裡氏替換原則（LSP liskov substitution principle）：

• 子類可以擴充父類的功能，但不能改變原有父類的功能；
• 實際項目中，每個子類對應不同的業務含義，使父類作為參數，傳遞不同的子類完成不同的業務邏輯；

3.依賴倒置原則（dependence inversion principle）：

• 面向接口程式設計，抽象就是接口或者抽象類，細節就是實作類；
• 上層子產品不應該依賴下層子產品，兩者應依賴其抽象；
• 抽象不應該依賴細節，細節應該依賴抽象；
• 通俗點就是說變量或者傳參數，盡量使用抽象類，或者接口；

4.接口隔離（interface segregation principle）：

• 建立單一接口（擴充為類也是一種接口，一切皆接口）；
• 用戶端不應該依賴它不需要的接口；
• 類之間依賴關系應該建立在最小的接口上；
• 複雜的接口，根據業務拆分成多個簡單接口；　

5.迪米特原則（law of demeter LOD）：

• 最少知道原則，盡量降低類與類之間的耦合；
• 一個對象應該對其他對象有最少的了解；

6.開閉原則（open closed principle）：

• 用抽象建構架構，用實作擴充原則；（總綱）

　　任何事都是過猶不及，設計模式的六個設計原則也是一樣，制定這六個原則的目的并不是要我們刻闆的遵守他們，而需要根據實際情況靈活運用。對他們的遵守程度隻要在一個合理的範圍内，就算是良好的設計。

１．高内聚低耦合

• 單一職責：每個服務是針對一個單一職責的業務能力的封裝，專注做好一件事情；
• 輕量級的通信方式：同步RESTful（GET/PUT/POST...），異步（消息隊列/釋出訂閱）；
• 不推薦在服務與服務之間共享資料庫；

２．高度自治

• 獨立部署運作，部署，釋出;
• 程序隔離:獨立開發和演進,獨立的代碼庫，流水線；
• 獨立的團隊和自治:團隊對服務的整個生命周期負責，工作在獨立的上下文中， 誰開發，誰維護。

３．以業務為中心

• 每個服務代表了特定的業務邏輯
• 有明顯的邊界上下文
• 能快速的響應業務的變化
• 隔離實作細節，讓業務領域可以被重用

４．彈性設計

• 設計可容錯的系統,擁抱失敗,為已知的錯誤而設計:錯誤如依賴的服務挂掉,網絡連接配接問題;
• 設計具有自我保護能力的系統:服務隔離,服務降級,限制使用資源,防止級聯錯誤;

５．日志與監控

      當産品環境出錯時，需要快速的定位問題，檢測可能發生的意外和故障。而日志與監控是快速定位和預防的不二選擇，在微服務架構中至關重要。

６．自動化

        當服務規模化後需要更多​

​自動化​

​​和​

​标準化​

​的手段來提升效能和降低成本。

• 自動化測試必不可少，因為對比單塊系統，確定我們大量的服務正常工作是一個更複雜的過程。
• 調用一個統一的指令行，以相同的方式把系統部署到各個環境。
• 考慮使用環境定義來幫助你明确不同環境間的差異，但同時保持使用統一的方式進行部署的能力。
• 考慮建立自定義鏡像來加快部署，并且擁抱全自動化建立不可變伺服器的實踐。

​