本文來自 fairjm@圖靈社群 轉截請註明出處

---

現實情況，軟體開發不是一個定義和執行的線性過程，而是一個進化的過程，通過和使用者交流學習、交付不斷迭代。

很多傳統的基於瀑布流方法的軟體製品有以下的特徵:

• 緊耦合：可能一個很細微的改動會影響整個應用並帶來新的bug。   
• 有漏洞(Leaky)
• 抽象洩露：一個開發團隊直接訪問屬於其他團隊的資料。造成了資料之間的隱式依賴 一些元件的內部資料結構會洩露到整個應用中   巨石：單一原始碼庫

而基於微服務的架構有以下的特徵:

•  有約束的(Constrained)：單一責任，範圍狹窄。做一件事並把他做好。
•  鬆耦合
•  抽象：微服務對自己的資料結構和資料來源完全掌控。
•  獨立：開發 編譯 部署都是獨立的。

微服務的特性對於基於雲的開發很重要。
基於雲的應用通常有以下幾個特徵：

•  龐大而多樣化的使用者群：想要很快使用一些新特性。新特性的交付比較足夠快。微服務允許因為很小所以允許特性被很快交付；
•  極高的線上時間需求  ；
•  不平等的資源需求:不同的微服務所需資源不對等。  

對於微服務，不同角色的職責：

•  架構師：有大局觀，瞭解應該如何拆分微服務，微服務之間如何互動來解決問題；
•  軟體開發者：寫程式碼，瞭解使用什麼語言和框架來交付微服務；
•  DevOps工程師：在所有環境下的服務部署和管理。每個環境下的一致性和可重複性。

2.1 架構師的故事：設計微服務架構

在專案中 架構師的角色是對於需要解決的問題提供一個工作模型（working model）
提供一個腳手架讓開發去填。

2.1.1 分解商業問題

分解問題到幾個關鍵的部分，然後在這些部分中尋找相互間的關係。

• 描述商業問題，記下主要的名詞。
• 注意動詞。標識著具體商業行為。  
• 找尋資料內聚。找到彼此間高度相關的資料

2.1.2 確定服務粒度

• 從一個較大的服務開始比較小的開始要好：可以從業務不斷拆分。而一開始就很小容易造成微服務變成了資料服務。
• 關注服務間互動。
• 服務職責會隨著你對問題域的理解發生改變。

一些不好的味道:
太粗了：表太多 測試用例太多 太多職責
太細了：相互依賴過於嚴重 服務變成了CRUD操作的集合

不斷迭代演化，而不是一開始就拿出一個完美的設計。

2.1.3 服務介面

REST URI JSON 狀態碼 服務介面要易於理解和使用。

2.2 什麼時候不要使用微服務

沒有很好的自動化運維
伺服器的開銷
應用規模小 使用者量小
多個資料來源的複雜資料聚合和轉換 記住在微服務間執行事務還沒有標準存在

2.3 開發者的童話：使用Spring Boot和java構建微服務

為什麼使用JSON:
輕量(對比SOAP的大量額外內容開銷）
容易閱讀和理解
預設的JS序列化協議

儘量早一點對建立URL的版本控制
mvn spring-boot:run

2.4 DevOps的故事：建立苛刻的執行時

寫程式碼簡單，保持執行難。
服務組裝
啟動
服務發現
監控

方法論:
https://12factor.net/