### 什么是微服務 微是指小的意思，服務是一個獨立運行的單元組件，每個單元組件運行在獨立的進程中，組件與組件之間通常使用HTTP這種輕量級的通信機制進行通信； 微服務是一種架構風格，一個大型復雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注于完成一件任務并很好地完成該任務。在所有情況下，每個任務代表著一個小的業務能力 ### 微服務拆分維度 針對微服務架構，普遍達成的共識是從業務角度驅動服務的識別與分解，我稱其為微服務的“業務維度” ### 微服務主要功能 * 服務的注冊和發現 * 服務的負載均衡 * 服務的容錯 * 服務網關 * 服務配置管理 * 鏈路追蹤 * 實時日志 ### 微服務架構的優點 * 每個服務都比較簡單，只關注于一個業務功能。 * 微服務架構方式是松耦合的，可以提供更高的靈活性。 * 微服務可通過最佳及最合適的不同的編程語言與工具進行開發，能夠做到有的放矢地解決針對性問題。 * 每個微服務可由不同團隊獨立開發，互不影響，加快推出市場的速度。 * 微服務架構是持續交付\(CD\)的巨大推動力，允許在頻繁發布不同服務的同時保持系統其他部分的可用性和穩定性 ### 微服務架構的缺點 * 運維開銷及成本增加：整體應用可能只需部署至一小片應用服務區集群，而微服務架構可能變成需要構建/測試/部署/運行數十個獨立的服務，并可能需要支持多種語言和環境。這導致一個整體式系統如果由20個微服務組成，可能需要40~60個進程。 * 必須有堅實的DevOps開發運維一體化技能：開發人員需要熟知運維與投產環境，開發人員也需要掌握必要的數據存儲技術如NoSQL，具有較強DevOps技能的人員比較稀缺，會帶來招聘人才方面的挑戰。 * 隱式接口及接口匹配問題：把系統分為多個協作組件后會產生新的接口，這意味著簡單的交叉變化可能需要改變許多組件，并需協調一起發布。在實際環境中，一個新品發布可能被迫同時發布大量服務，由于集成點的大量增加，微服務架構會有更高的發布風險。 * 代碼重復：某些底層功能需要被多個服務所用，為了避免將“同步耦合引入到系統中”，有時需要向不同服務添加一些代碼，這就會導致代碼重復。 * 分布式系統的復雜性：作為一種分布式系統，微服務引入了復雜性和其他若干問題，例如網絡延遲、容錯性、消息序列化、不可靠的網絡、異步機制、版本化、差異化的工作負載等，開發人員需要考慮以上的分布式系統問題。 * 異步機制：微服務往往使用異步編程、消息與并行機制，如果應用存在跨微服務的事務性處理，其實現機制會變得復雜化。 * 可測性的挑戰：在動態環境下服務間的交互會產生非常微妙的行為，難以可視化及全面測試。經典微服務往往不太重視測試，更多的是通過監控發現生產環境的異常，進而快速回滾或采取其他必要的行動。但對于特別在意風險規避監管或投產環境錯誤會產生顯著影響的場景下需要特別注意 ### 微服務架構三大難題 * 服務故障的傳播性：熔斷機制 * 服務的劃分 * 分布式事務 _**參考資料**_ [https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/解析微服務架構\_一\_什么是微服務?lang=en](https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/解析微服務架構_一_什么是微服務?lang=en) [http://blog.didispace.com/20160917-microservices-note/](http://blog.didispace.com/20160917-microservices-note/)