什麼是微服務？這是一個巨大的問題，而我們只先需要一個微小的答案。
就好像軟體架構：分層架構模式一樣，微服務同樣是一種設計軟體架構的方法。微服務就是由一群很小又自治的獨立服務所組成的軟體系統。
足夠的小
很小，到底是有多小？是使用程式行數來衡量的嗎？但有些語言就是相對精簡。又或是以面向的內容而定？
按照 SOLID 原則的單一職責原則而言，用內聚性來為服務分類可能是一個不錯的方向。我們可以把面向相同角色的程式放到同一個服務當中，這樣正好很容易的確定該服務的業務邊界。
還是說，我們可以按照團隊的結構來為服務的大小設置上限？如果程式的大小是團隊無法正常維護的話，那就是太大了？但這樣卻會突顯出一個問題，如果我的團隊超級大，我們是不是就可以建一個超大的服務？甚至變成一個巨大單體服務？這樣好像正正又違反了微服務的設計理念！
到底多大才會一個微服務適合的大小，這是一個沒有標準答案回答的問題。因為每個專案、每個團隊都有他們的喜好與困難，適合 Amazon 的不一定適合大型銀行。我的答案是，當你意識到某服務「過大」時，就是應該拆分縮小的時候了。
自治？
如果服務間可以獨立進行操作，我們就可以說該服務是自治的嗎？如果服務會容易受到其他相依的服務影響，該服務還是具自治性嗎？我們該使用什麼機制來保持服務之間的自治性？
一個微服務應當是一個可以獨立運行的實體。服務間應該可以彼此間分離進行修改，並其修改不應該引起其他服務的變動。另外，服務間通過 API 來進行溝通，從而加強了服務之間的隔離性。但是同樣地，我們需要考慮服務之間該暴露多少資訊，若暴露過多則會產生額外的耦合性，從而降低自治性。
從以上架構圖，我們可以看到 eShop 的 Client apps 分別連線到不同的 API Gatewats/BFF 中，再對不同的微服務進行溝通，不同功能的服務又有不同的技術棧。
微服務的優點：
- 縮窄職責範圍
當每個服務只專注於自已的業務邊界時，團隊會更易於管理與支援專案，更易於培養相關專才，任何人都可以更快的上手。同時，也可以減少因某範圍的程式瓶頸而造成的影響。 - 性能與可擴展性
每個服務可以完全按照自己需求來選擇技術棧，從程式語言、設計構架到框架與資料庫都可以完全為了最適合的情景來進行報置。如此相比單體架構，更能保持彈性與解耦。服務性能也可以按照不同的需求而適整，如某一服務需要大量需求，那我們也只需要擴展與優化該服務，從而有針對性且有效地提高性能又節省成本。 - 加快開發與釋出周期
因為每個服務都是相對的小而自治，所以服務的開發周期都會加快。這得益於服務可以獨立開發且低耦合於其他服務，可以單獨地進行測試與部置，所以大大地提升了軟體的開發周期。 - 可組合性
在微服務中，人們可以根據不同的目的而使用同一個服務，這使得我們在考慮不同平台的軟體開發時，更易於做整體的考慮。當有需求改變時，可以使用不同的型式來組合成新的應用，而不用被整個巨大單體軟體困住。
微服務的缺點：
- 困難性
嗯。。。就是困難！微服務要架構得好是一件相當困難而極需經驗的「技藝」，從為業務分邊界開始，這就一度大難題。如何分才是好或適合？服務之間的通訊與成本該如何處理？我們該如何確保不同服務之間的資料的統一性？團隊架構足以應付微服務的開發模式嗎？在產品上要監制不同的服務會變得越加複雜。 - 資料重複性
服務之間的資料交換，通常都會造成大量的資料重複，因為每個服務需要獨立地運作，而共用資料庫是不可取的。因而，資料會被不同服務重複存取，最後造成資源浪費。 - 資安管理更複雜
每個服務都要各自維護各自的資安品質，因此更易出現漏洞，而要發現問題也變得更困難，因此過度或缺少對資安方面的投入都是有可能的。 - 錯誤管理更果難
由於每個服務都由不同團隊維護，在錯誤分析時會變得更費時與複雜，亦更難以追蹤日誌。
如果你覺得我的文章幫助到你，希望你也可以為文章拍手，分別 Follow 我的個人頁與程式愛好者，按讚我們的粉絲頁喔，支持我們推出更多更好的內容創作！
