爲何要微服務化

技術交流羣：233513714

 

六大優點

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

一、複雜度可控：在將應用分解的同時，規避了本來複雜度無止境的積累。每個微服務專一於單一功能，並經過定義良好的接口清晰表述服務邊界。因爲體積小、複雜度低，每一個微服務可由一個小規模開發團隊徹底掌控，易於保持高可維護性和開發效率。

二、獨立部署：因爲微服務具有獨立的運行進程，因此每一個微服務也能夠獨立部署。當某個微服務發生變動時無需編譯、部署整個應用。由微服務組成的應用至關於具有一系列可並行的發佈流程，使得發佈更加高效，同時下降對生產環境所形成的風險，最終縮短應用交付週期。

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

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

五、擴展：單塊架構應用也能夠實現橫向擴展，就是將整個應用完整的複製到不一樣的節點。當應用的不一樣組件在擴展需求上存在差別時，微服務架構便體現出其靈活性，由於每一個服務能夠根據實際需求獨立進行擴展。

六、功能特定：一個微服務通常完成某個特定的功能，好比消息管理、客戶管理等等。每個微服務都有本身的業務邏輯和適配器。一些微服務還會發布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統計和監控