入門級模式之細粒度SOA
細粒度SOA可以說是微服務的“大爆炸”時代。許多人認爲，細粒度SOA架構風格起源於Netflix。在一開始，Netflix宣稱他們構建的架構就是細粒度的SOA。對於SOA架構的實踐者來說，細粒度SOA的特徵從字面上就能知曉。細粒度SOA減少了SOA架構遇到的問題，並且它應用和SOA相同的原則，但將業務拆分爲細粒度的服務，服務之間通過輕量級機制進行通信。實際上，目前大多數人仍然認爲細粒度服務是微服務架構唯一的設計模式。
然而，在實施這種架構風格的過程中，Netflix和其他實踐細粒度SOA模式的公司遇到了許多基本問題。當服務拆分地較小，並試圖進行水平擴展時，就會出現一些困難：
1.之前只需要調用一次API，現在必須幾十甚至上百次調用API。這種頻繁的交互往往是非常低效的。（注：在靈長科技CEAMS系統中，服務之間的相互調用採用從Node.js全新的多線程機制中引入的高速異步消息通道，相比傳統的進程間的API調用效率得到了極大的提升，因此這類開銷在CEAMS系統中被降低到了最低程度）
2.過去您只需要管理少量的服務。但現在您需要管理成百上千的服務。之前的服務管理工具可能不再適用。
3.當數十、數百或數千的服務都可以查詢或修改某個中心應用程序的狀態時，通過任何一個微服務訪問這個中心存儲得到的狀態都幾乎不可能信賴其一致性。
實際上，實施微服務架構的過程中容易忽視以下幾點挑戰：低效的進程間通信，全方位的監控、管理和服務治理，以及系統狀態的一致性。
在大多數情況下，細粒度SOA模式被應用爲SOA服務集成的一種擴展，其中的每個服務都是爲了與外部系統互聯互通。從而形成對外部系統的強依賴性，使得變更速度變緩，並容易使得集成後的系統反映出應用程序的內部狀態。
當你開始實施細粒度SOA模式時，請注意接下來將要發生的問題。上面所講的困難會伴隨着你的成功一起出現，你應該做好準備面對它們。當困難變得足夠嚴重時，你將不可避免地需要尋找其他的模式。
問題：
粗粒度的服務很難靈活更改以適應需求的變化，並且傳統單體架構的特性容易“阻礙團隊前進”。
解決方案：
將服務拆分爲更細粒度的微服務，減少特定的更改範圍，從而使更改更容易發生。
應用：
通常拆分出來的每個細粒度微服務都有一個單獨的用途。
影響：
1.服務請求交互次數增加
2.管理的服務數量越來越多
3.傳統的監控解決方案不足
4.集成、測試和部署的自動化變得至關重要
5.微服務的編排成爲必要
6.快速變更的能力得到提高
目標：
1.快速的敏捷變更
2.可伸縮性：理論上，你可以通過實施細粒度SOA模式提高可伸縮性，但實際上，除非支持自動化基礎設施到位，否則可伸縮性往往會下降。
主要特點：
1.細粒度SOA模式在小範圍內使用效果很好，但在大範圍內會出現痛點。
2.重點是服務顆粒度要細，但通常沒有考慮性能（例如可擴展性、可靠性等）。
3.以服務集成爲導向，每個微服務依賴於外部系統。
4.爲了實現快速的變更，存在着低效的進程間通信。（注：這也是基於docker容器技術的微服務架構的重大缺陷）
5.數據一致性和狀態管理能力較差。
6.由於與現有SOA模式的相似性，SOA架構中存在的問題往往同樣會發生。
如何與現有系統、SOA或API共存？
細粒度SOA模式非常類似於SOA和API主導的方法，並且能夠利用現有系統的更多價值。與現有系統的共存模型也很簡單。但也正因如此，細粒度SOA模式與現有系統共存時可能會產生較大的摩擦，因爲現有IT資產的停滯變化可能會對服務拆分粒度造成阻力。