六大優勢

微服務架構相對於傳統的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統計和監控

為什麽要微服務化