【編者按】

近幾年，隨著云計算技術的進步和服務的增長，微服務越來越成為在博客、媒體討論組和會議演講中出現的熱門話題，被更多的人重點關注。正如本文作者 51CTO博客專家孫杰在文中提到的，盡管微服務架構存在著許多爭論，但這并不影響它正在為敏捷部署以及復雜企業應用實施提供著巨大的幫助的事實。究竟我們為什么需要微服務架構？與傳統SOA相比，微服務架構有哪些優勢？在使用微服務架構時，我們又將面臨哪些挑戰？

作者簡介

[[162176]]

孫杰，51CTO博客專家博主

孫杰，擁有超十二載IT領域工作經驗，先后在知名外企、電商平臺和國企能源行業的數據中心從事IT系統架構搭建、云計算、大數據架構部署及運維等工作。熱愛技術喜歡分享，崇尚大道至簡。在若干大中型項目的建設和運維中，積累了豐富的系統運維、架構設計、平臺優化等經驗。在博客平臺發布了大量IT技術和生活文章，并成為51CTO平臺上的專家博主。

如何理解微服務

微服務這一概念出現于2012年，是因軟件作者Martin Fowler而流行，圍繞業務、自動化部署、終端智能以及語言和數據的分散控制有一些常見的新特性。微服務也是一項在云中部署應用和服務的新技術。隨著云計算技術的進步和服務的增長，微服務架構越來越多的受到了人們的關注。盡管也存在著許多不同的爭論，微服務架構模式卻正在為敏捷部署以及復雜企業應用實施提供著巨大的幫助。

通常我們的開發也是模塊化設計邏輯，程序完成后會打包并部署為一個個具體的應用。每個具體的格式依賴于相應的應用語言和框架。例如，Java應用通常會被打包為WAR格式，部署在Tomcat或者Jetty上，而另外一些Java應用會被打包成自包含的JAR格式，同樣，Rails和Node.js會被打包成層級目錄。這種應用開發風格很常見，也很易于調試，只需要簡單運行此應用，用些工具鏈接UI就可以完成端到端測試。打包好的應用拷貝到服務器端，通過在負載均衡器后端運行多個拷貝就可以輕松實現應用擴展。在早期這類應用運行的都很好，但一個簡單的應用會隨著時間推移逐漸變大。幾年后，這個小而簡單的應用會變成了一個巨大的怪物。一旦你的應用變成一個龐大而又復雜的怪物，那開發團隊肯定很痛苦。敏捷開發和部署舉步維艱，其中最主要問題就是這個應用太復雜，以至于任何單個開發者都不可能搞懂它。因此，修正bug和正確的添加新功能將變的非常困難，并且很耗時。

當一個應用越大，啟動時間就會越長。那么大部分時間就要在等待中渡過，生產效率會受到極大影響。

另外，一個應用在不同模塊發生資源沖突時，擴展將會非常困難。應用的另外一個問題是可靠性。當所有模塊都運行在一個進程中，任何一個模塊中的一個bug，比如內存泄露，將會有可能弄垮整個進程。除此之外，因為所有應用實例都是唯一的，這個bug將會影響到整個應用的可靠性。

如果采用微服務處理結構模式則可以很好的解決上述問題。微服務架構的思想不是開發一個復雜巨大的應用，而是將應用分解為若干小的、互相連接的微服務。

[[162177]]

六大優勢

微服務架構相對于傳統的SOA，優勢也很明顯：

1、復雜度可控：在將應用分解的同時，規避了原本復雜度無止境的積累。每一個微服務專注于單一功能，并通過定義良好的接口清晰表述服務邊界。由于體積小、復雜度低，每個微服務可由一個小規模開發團隊完全掌控，易于保持高可維護性和開發效率。

2、獨立部署：由于微服務具備獨立的運行進程，所以每個微服務也可以獨立部署。當某個微服務發生變更時無需編譯、部署整個應用。由微服務組成的應用相當于具備一系列可并行的發布流程，使得發布更加高效，同時降低對生產環境所造成的風險，最終縮短應用交付周期。

3、技術選型靈活：微服務架構下，技術選型是去中心化的。每個團隊可以根據自身服務的需求和行業發展的現狀，自由選擇最適合的技術棧。由于每個微服務相對簡單，當需要對技術棧進行升級時所面臨的風險較低，甚至完全重構一個微服務也是可行的。

4、容錯：當某一組建發生故障時，在單一進程的傳統架構下，故障很有可能在進程內擴散，形成應用全局性的不可用。在微服務架構下，故障會被隔離在單個服務中。若設計良好，其他服務可通過重試、平穩退化等機制實現應用層面的容錯。

5、擴展：單塊架構應用也可以實現橫向擴展，就是將整個應用完整的復制到不同的節點。當應用的不同組件在擴展需求上存在差異時，微服務架構便體現出其靈活性，因為每個服務可以根據實際需求獨立進行擴展。

6、功能特定：一個微服務一般完成某個特定的功能，比如消息管理、客戶管理等等。每一個微服務都有自己的業務邏輯和適配器。一些微服務還會發布API給其它微服務和應用客戶端使用。其它微服務完成一個Web UI，運行時，每一個實例可能是一個云VM或者是Docker容器。

三大挑戰

1.固有的復雜性：微服務架構有很多優點，當然也有其不足。比如微服務應用是分布式系統，由此會帶來固有的復雜性。開發者需要在RPC或者消息傳遞之間選擇并完成進程間通訊機制。更甚于，他們必須寫代碼來處理消息傳遞中速度過慢或者不可用等局部失效問題。

2.分區的數據庫架構：另外一個關于微服務的挑戰來自于分區的數據庫架構。在商業交易系統中同時給多個業務分主體更新消息很普遍。這種交易對于單個應用來說很容易，因為只有一個數據庫。而在微服務架構應用中，需要更新不同服務所使用的不同的數據庫。使用分布式交易并不一定是好的選擇，不僅僅是因為CAP理論，還因為今天高擴展性的NoSQL數據庫和消息傳遞中間件并不支持這一需求。最終你不得不使用一個最終一致性的方法，從而對開發者提出了更高的要求和挑戰。

3.波及多個服務：***一個問題在于，微服務架構模式應用的改變將會波及多個服務。比如，假設你在完成一個項目案例，需要修改服務A、B、C，而A依賴B，B依賴C。在單個應用中，你只需要改變相關模塊，整合變化，部署就好了。相比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。比如，你需要更新服務C，然后是B，***才是A，幸運的是，許多改變一般只影響一個服務，而需要協調多服務的改變很少。

使用微服務構建適合云的新型應用是很有意義的，因為它讓你既利用了橫向擴展架構，也利用了縱向擴展架構，還額外得到API的組合，且在整個業務中可重復利用。可能在每一分鐘都在交付新服務，這樣你就會擁有一個敏捷的且即時響應的應用程序平臺，當然這一平臺一直在不斷改進中，微服務架構也在前進著。

主要周邊技術

• 云VM
• DOCKER容器
• 微服務架構與SOA
• 微服務與分布式
• 微服務與數據一致性
• 微服務與數據庫
• 微服務與PAAS
• 微服務與自動化部署
• 微服務與Mesos或者Kubernetes
• 微服務層面如何提供緩存、權限控制、API統計和監控