關于微服務、SOA、以及API的了解

　　現在微服務、SOA、RESTful API設計等在各大公司很流行。微服務(micro services)這個概念不是新概念，很多公司已經在實踐了，例如亞馬遜、Google、FaceBook，Alibaba。微服務架構模式(Microservices Architecture Pattern)的目的是将大型的、複雜的、長期運作的應用程式建構為一組互相配合的服務，每個服務都可以很容易得局部改良。 Micro這個詞意味着每個服務都應該足夠小，但是，這裡的小不能用代碼量來比較，而應該是從業務邏輯上比較——符合SRP原則的才叫微服務。但是微服務和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架構）

　　當然，這隻是其中能想到的幾點，實際環境中用到的微服務架構有可能會根據實際業務需求優化出更加個性化的功能，也可能有些功能是不需要的。還是那句話，架構是服務于業務的，能快速友善的滿足業務需求的架構才是好的架構，才是好的微服務架構。

三.微服務架構的優點與缺點

1. 優點

• 每個服務足夠内聚，足夠小，代碼容易了解、開發效率提高
• 服務之間可以獨立部署，微服務架構讓持續部署成為可能;
• 每個服務可以各自進行x擴充和z擴充，而且，每個服務可以根據自己的需要部署到合适的硬體伺服器上;
• 容易擴大開發團隊，可以針對每個服務(service)元件開發團隊;
• 提高容錯性(fault isolation)，一個服務的記憶體洩露并不會讓整個系統癱瘓;
• 系統不會被長期限制在某個技術棧上。

2. 缺點

• 開發人員要處理分布式系統的複雜性;開發人員要設計服務之間的通信機制，對于需要多個後端服務的user case，要在沒有分布式事務的情況下實作代碼非常困難;涉及多個服務直接的自動化測試也具備相當的挑戰性;
• 服務管理的複雜性，在生産環境中要管理多個不同的服務的執行個體，這意味着開發團隊需要全局統籌(PS：現在docker的出現适合解決這個問題)
• 應用微服務架構的時機如何把握?對于業務還沒有理清楚、業務資料和處理能力還沒有開始爆發式增長之前的創業公司，不需要考慮微服務架構模式，這時候最重要的是快速開發、快速部署、快速試錯。