我所理解的SOA和微服務

本文原創，原文地址爲：http://www.cnblogs.com/fengzheng/p/5847441.html 

SOA和微服務究竟是什麼關係？

說實話，我確實不明白SOA和微服務到底有什麼本質上的區別，二者說到底都是對外提供接口的一種架構設計方式。我倒以爲微服務其實就是隨着互聯網的發展，複雜的平臺、業務的出現，致使SOA架構向更細粒度、更經過化程度發展，就成了所謂的微服務了。以這種說法作爲根據，我以爲SOA與微服務的區別在於以下幾個方面：

1. 微服務相比於SOA更加精細，微服務更多的以獨立的進程的方式存在，互相之間並沒有影響；
2. 微服務提供的接口方式更加通用化，例如HTTP RESTful方式，各類終端均可以調用，無關語言、平臺限制；
3. 微服務更傾向於分佈式去中心化的部署方式，在互聯網業務場景下更適合；

爲何要使用微服務？

技術爲業務而生，架構也爲業務而出現，固然SOA和微服務也是由於業務的發展而出現。出現SOA和微服務框架與業務的發展、平臺的壯大密不可分，下面借用dubbo的網站架構發展圖和說明：

• 單一應用架構
  • 當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
  • 此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
• 垂直應用架構
  • 當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
  • 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
• 分佈式服務架構
  • 當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  • 此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
• 流動計算架構
  • 當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
  • 此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

平臺隨着業務的發展從 All in One 環境就能夠知足業務需求（以Java來講，可能只是一兩個war包就解決了）；發展到須要拆分多個應用，而且採用MVC的方式分離先後端，加快開發效率；在發展到服務愈來愈多，不得不將一些核心或共用的服務拆分出來，其實發展到此階段，若是服務拆分的足夠精細，而且獨立運行，我以爲就能夠將之理解爲一個微服務了。

理想中的微服務架構

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

1. 能支持當前業務需求，固然這只是最最基本的條件；
2. 每一個微服務都要去中心化，不存在單點故障；
3. 每一個微服務都要實現高可用、高負載，不會由於一個服務不可用而影響了整套業務流；
4. 每一個微服務都要高度通用化，即多種終端均可調用，不分語言和平臺；
5. 服務部署或升級簡單，不會消耗大量人力而且部署過程不易出現人爲錯誤；
6. 微服務具備快速註冊與自動發現功能（例如dubbo框架）

固然，這只是其中能想到的幾點，實際環境中用到的微服務框架有可能會根據實際業務需求優化出更加個性化的功能，也可能有些功能是不須要的。仍是那句話，架構是服務於業務的，能快速方便的知足業務需求的架構纔是好的架構，纔是好的微服務架構。

 

歡迎關注公衆號「gushidefengzheng」古時的風箏

還能夠加入 Java 微信討論羣（若是二維碼過時：請加微信:fengdezitai001 ,備註：cnblogs）：

以上只是我的理解，將本身的理解寫出，以備本身查看。

也許我說的並必定對，也許我說的全是錯的。