微服務架構模式成熟之前，軟件領域討論的比較多的是SOA的架構模式。SOA早在1996年就由Gartner提出，作為面向服務的架構模式，SOA的理念是對于復雜的企業IT系統，按照不同的、可重用的粒度劃分，將功能相關的一組功能提供者組織在一起為消費者提供服務。SOA在實際的發展過程中并不順利，隨著ESB(Enterprise Service Bus)、Web Service、SOAP等技術出現，SOA才漸漸落地。但其主要解決的是企業內部不同IT資源之間的信息共享、互通等問題，相當長時間內的發展依賴于企業級軟件總線的進展，而這類軟件總線總體上厚重、大而全，但相互之間由不同的軟件廠家提供，自成體系無法互通，從而又制約了其發展。從SOA的面向服務而言，其與微服務架構模式中的服務化這類思想是基本一致的。落地實踐的過程中，微服務與SOA又有著明顯的區別。
最準確的說法：微服務是SOA的一種實現
最實際的說法：微服務是去ESB的SOA
實際上是兩種思想的分歧：分布還是集中
當然這里說的不是服務的分布和集中。服務肯定是分布的，這是大前提，是SOA的本質理念之一。分歧在于對服務的治理，是分布還是集中。
SOA
SOA的提出是在企業計算領域，就是要將緊耦合的系統，劃分為面向業務的，粗粒度，松耦合，無狀態的服務。服務發布出來供其他服務調用，一組互相依賴的服務就構成了SOA架構下的系統。
基于這些基礎的服務，可以將業務過程用類似BPEL流程的方式編排起來，而BPEL反映的是業務處理的過程，這些過程對于業務人員更為直觀，調整也比hardcode的代碼更容易。
當然企業還需要對服務治理，比如服務注冊庫，監控管理等。
我們知道企業計算領域，如果不是交易系統的話，并發量都不是很大的，所以大多數情況下，一臺服務器就容納將許許多多的服務，這些服務采用統一的基礎設施，可能都運行在一個應用服務器的進程中。雖然說是面向服務了，但還是單一的系統。
微服務
而微服務架構大體是從互聯網企業興起的，由于大規模用戶，對分布式系統的要求很高，如果像企業計算那樣的系統，伸縮就需要多個容納續續多多的服務的系統實例，前面通過負載均衡使得多個系統成為一個集群。
但這是很不方便的，互聯網企業迭代的周期很短，一周可能發布一個版本，甚至可能每天一個版本，而不同的子系統的發布周期是不一樣的。
而且，不同的子系統也不像原來企業計算那樣采用集中式的存儲，使用昂貴的Oracle存儲整個系統的數據，二是使用MongoDB，HBase，Cassandra等NOSQL數據庫和Redis，memcache等分布式緩存。
那么就傾向采用以子系統為分割，不同的子系統采用自己的架構，那么各個服務運行自己的Web容器中，當需要增加計算能力的時候，只需要增加這個子系統或服務的實例就好了，當升級的時候，可以不影響別的子系統。這種組織方式大體上就被稱作微服務架構。
微服務與SOA相比，更強調分布式系統的特性，比如橫向伸縮性，服務發現，負載均衡，故障轉移，高可用。互聯網開發對服務治理提出了更多的要求，比如多版本，比如灰度升級，比如服務降級，比如分布式跟蹤，這些都是在SOA實踐中重視不夠的。
Docker容器技術的出現，為微服務提供了更便利的條件，比如更小的部署單元，每個服務可以通過類似Node.js或Spring Boot的技術跑在自己的進程中。可能在幾十臺計算機中運行成千上萬個Docker容器，每個容器都運行著服務的一個實例。隨時可以增加某個服務的實例數，或者某個實例崩潰后，在其他的計算機上再創建該服務的新的實例。
文章列表
留言列表
