近些年來，SOA（Service Oriented Architecture）、微服務等概念發展得如火如荼，也在各大公司、各主流產品上得到了成功的實踐，並積累了正反兩方面的經驗。SOA思想的關鍵，在我看來，主要可分爲分、合、細三個維度。
- 分：是指將之前無比複雜、無比龐大的系統按照橫向（按業務需求）、縱向（按功能層次）劃分成高內聚、低相互間耦合的服務或模塊；
- 合：是指將通用的功能（比如日誌記錄、鑑權處理等）抽象、提取出來，放在通用的服務或模塊中，由該服務或模塊統一提供這部分通用功能，對其他服務或模塊屏蔽該功能的實現細節，從而使得功能的迭代與升級，都能夠限制在通用服務或模塊的內部，外部無感知、無影響；
- 細：所謂細是深耕功能、不斷細化的過程。通過功能劃分，我們能夠將某一塊業務或通用功能提取、抽象出服務，然後將散落在各處的屬於這一塊業務的細節或通用功能合併至該服務中，不斷深耕、不斷細化，將功能做細，將業務做大做強。
SOA的引入，帶來了以下的優點：
- 系統的搭建更加方便快捷，如果能夠更好地藉助已有的通用功能或通用業務模塊的話；
- 業務迭代更加方便快捷，不至於發佈一個非常小的且非常獨立的功能就將整個無比複雜的系統編譯一遍，進行上線，而是僅需要發佈相關的服務即可；
- 系統擴展性好，隨着流量的增加，只需要對成爲或即將成爲流量瓶頸的模塊進行橫向擴容即可。
當然，正如古語所說之“有一利就有一弊”。SOA概念的引入也給系統設計、部署、運行帶來了諸多麻煩，需要進行額外引入組件進行解決。這些問題主要有：
- 分佈式協調，即集羣一致性如何得到保證；
- RPC（Remote Procedure Call）框架，如何通過框架提供不同服務間像調用本地進程方法那樣進行RPC調用的能力；
- 消息異步通知：由於是SOA型的架構，因此服務間的消息通知是不可避免的。如果說RPC更多是提供了一種同步消息通知的方式，那麼Message Queue則對異步消息通知提供瞭解決方案，當前業界有多種MQ產品，RabbitMQ，RocketMQ，kafka等，使用者可根據具體的使用場景進行相應的MQ技術選型；
- 服務發現與服務治理，即對於調用方，能夠方便快捷地發現所需要引用的服務；對於服務提供方，能夠方便快捷地告知集羣其能夠提供服務。除此以外，還需要提供服務性能監控（響應時間、流量統計）、服務鑑權、服務降級等功能。
- 負載均衡，按某種規則（可能是簡單的平均，也可能是對機器服務能力加以考量之後的加權平均）對負載流量進行切分。
不過幸運的是，目前針對這些問題均有相應的解決方案，並經歷了大流量、低延遲使用場景的檢驗。我會在後續的文章中一一加以介紹。