SOA和微服務到底是什么關系？

說實話，我確實不明白SOA和微服務到底有什么本質上的區(qū)別，兩者說到底都是對外提供接口的一種架構設計方式。我倒覺得微服務其實就是隨著互聯網的發(fā)展，復雜的平臺、業(yè)務的出現，導致SOA架構向更細粒度、更通過化程度發(fā)展，就成了所謂的微服務了。以這種說法做為根據，我覺得SOA與微服務的區(qū)別在于如下幾個方面：

微服務相比于SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間并無影響；

微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各種終端都可以調用，無關語言、平臺限制；

微服務更傾向于分布式去中心化的部署方式，在互聯網業(yè)務場景下更適合；

為什么要使用微服務？

技術為業(yè)務而生，架構也為業(yè)務而出現，當然SOA和微服務也是因為業(yè)務的發(fā)展而出現。出現SOA和微服務框架與業(yè)務的發(fā)展、平臺的壯大密不可分，下面借用dubbo的網站架構發(fā)展圖和說明：

單一應用架構

當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節(jié)點和成本。

此時，用于簡化增刪改查工作量的 數據訪問框架（ORM） 是關鍵。

垂直應用架構

當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。

此時，用于加速前端頁面開發(fā)的 Web框架（MVC） 是關鍵。

分布式服務架構

當垂直應用越來越多，應用之間交互不可避免，將核心業(yè)務抽取出來，作為獨立的服務，逐漸形成穩(wěn)定的服務中心，使前端應用能更快速的響應多變的市場需求。

此時，用于提高業(yè)務復用及整合的 分布式服務框架（RPC） 是關鍵。

流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基于訪問壓力實時管理集群容量，提高集群利用率。

此時，用于提高機器利用率的 資源調度和治理中心（SOA） 是關鍵。

平臺隨著業(yè)務的發(fā)展從 All in One 環(huán)境就可以滿足業(yè)務需求（以Java來說，可能只是一兩個war包就解決了）；發(fā)展到需要拆分多個應用，并且采用MVC的方式分離前后端，加快開發(fā)效率；在發(fā)展到服務越來越多，不得不將一些核心或共用的服務拆分出來，其實發(fā)展到此階段，如果服務拆分的足夠精細，并且獨立運行，我覺得就可以將之理解為一個微服務了。

理想中的微服務架構

沒有什么東西是完美的，網站架構也是這樣的，只有「比之前好一點」的架構或「目前最好的實現方式」，不存在理想中的架構，那么理想中微服務架構應該是怎么樣的呢，我覺得至少應該有如下幾個特點：

能支持當前業(yè)務需求，當然這只是最最基本的條件；

每個微服務都要去中心化，不存在單點故障；

每個微服務都要實現高可用、高負載，不會因為一個服務不可用而影響了整套業(yè)務流；

每個微服務都要高度通用化，即多種終端都可調用，不分語言和平臺；

服務部署或升級簡單，不會消耗大量人力并且部署過程不易出現人為錯誤；

微服務具有快速注冊與自動發(fā)現功能（例如dubbo框架）

當然，這只是其中能想到的幾點，實際環(huán)境中用到的微服務框架有可能會根據實際業(yè)務需求優(yōu)化出更加個性化的功能，也可能有些功能是不需要的。還是那句話，架構是服務于業(yè)務的，能快速方便的滿足業(yè)務需求的架構才是好的架構，才是好的微服務架構。