2017.6.1, Ken Fang, 深圳

在微服務的世界裡, 假如, 還只是在用幾十年前軟體工程的思維, 則將會為自身的微服務帶來失敗、毀滅性的災難。

@ 微服務ㄧ定要做場景分析、架構設計、介面設計、事件 （資訊）設計、整合測試用例設計。
但真正的重點是：假如這些微服務開發生命週期的活動, 不是經由視覺化、輕量級的工程實踐，而使市場（業務）人員, 架構師, 開發人員, 測試人員可共同的協作來完成, 卻還是由架構師單獨的完成場景分析、架構設計、介面設計、事件（資訊）設計；還是由測試人員單獨的完成整合測試用例，則微服務將面臨⋯

1. 由架構師所單獨設計出的微服務, 也許將使開發人員很難理解微服務的內部業務場景, 更糟糕的是, 將使開發人員在 Service Location 上陷入迷航。

2. 測試人員缺乏與市場（業務）人員、架構師、開發人員之間的協作, 則所設計出的整合測試用例, 將很難覆蓋到測試微服務應該有的廣度與深度。

@ 微服務要真正能達到持續佈署、按需釋出, 除了做好協作, 將微服務的設計做到位外, 更重要的是, 各微服務一定要從 “程式碼” 的層級就能達到隔離；而不只是在 “設計” 的層級達到隔離。所以, 在微服務的世界裡, 開發人員具備函式響應式程式設計的能力, 是最核心且是最重要的ㄧ件事。

當然, 老生常談的一件事是：在微服務的世界裡, 開發人員, 測試人員ㄧ定要具備分散式資料與事件流的理論知識。