本篇同步發文在個人Blog: 一袋.NET要扛幾樓？打造容器化的ASP.NET Core網站！系列文章 - (2) 傳統單一架構 VS 微服務架構

　傳統的單一系統架構，裡面的功能越做越大，導致後續維護越來越吃力。比如今天只要修改購物網站的會員功能，沒有更改其他程式碼，修改完畢後，光是編譯就得花不少時間，後續的測試與部署更不用說，只要中間過程一出錯，從頭來回修改的時間要很久。

　今天微服務架構的特性有兩個：

1. 小又專精：國軍知名口號「小而精、小而強、小而巧」，用在微服務洽好不過(?)，使相關功能的模組都收斂在一個服務，也符合單一職責原則。
2. 自治性：微服務各自部署在不同機器/平台，彼此開放API並用網路溝通，降低耦合性

　基於這些特性，所帶來的好處有：

1. 不同技術的Stack：每個微服務可以有自己的技術Stack，比如會員服務可以用ASP.NET Core + SQL Server，訂單服務可以用PHP + MySQL
2. 高彈性：即使有個服務壞了，其他服務仍可運作
3. 高擴展性：容易擴充服務，比如負載平衡
4. 簡化部署：只需針對要部署的服務，其他服務仍保持運作
5. 減少團隊共同的負擔：以前維護單一系統是所有團隊共同維護，一人更改就得全部受影響；使用微服務可讓團隊專注在自己的服務
6. 可組合性：微服務可支援多樣的前端應用
7. 替代性高：如果該服務需要換技術或者移除，比起傳統單一系統容易達成

　但微服務架構也有些缺點，要考慮分散式帶來的問題(比如CAP)，還有測試、部署、監控的工作與傳統單一系統不同。

　目前有些台灣公司找後端工程師，不限制使用的技術Stack，很有可能是採用微服務架構，可知這種架構是有幫助的。而我工作環境仍都是單一系統開發，只有Side Project能嘗試這新架構，而且微軟也為相關的文件寫得很充裕，非常的有用！下一篇會開始設計商品列表的Api，敬請期待。

參考資料：

.NET 微服務 - 架構電子書：微服務架構

Building Microservices: Designing Fine-Grained Systems：1. Microservices