前言
隨着各行各業的快速發展，業務規模的不斷擴大，不可避免地造成原有架構不能夠適應快速的增長和變化。這時，微服務就進入大家的視野，其實在微服務之前，很多公司已經做過服務化的改造，並且取得了一定的成果，但是對於整體流程的標準化還有一定有差距。那麼，什麼是微服務呢？
微服務概述
準確地說，微服務是一種軟件架構模式，將大型系統或者複雜的應用分割成多個服務的架構，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務都有獨立的生命週期，可以單獨維護和部署，各個業務模塊之間是松耦合的，比傳統的應用程序更有效地利用了計算資源，應用的擴展更加靈活，能夠通過擴展組件來處理功能瓶頸問題。這樣一來，開發人員只需要爲額外的組件部署計算資源，而不需要部署一個完整的應用程序的全新迭代。
一個微服務的架構如下圖所示，單體應用被拆分成多個微小的服務。
也有人將微服務的開發比喻成搭積木，每個服務都是一個零件， 使用這些不同的服務可以搭建出不同的形狀。簡單地說，微服務架構就是把一個大系統按業務功能分解成多個職責單一的小系統，並利用簡單的方法使多個小系統相互協作，組合成一個大系統。
其實這裏蘊含着自古以來的真理，就是分而治之，當一件事情大到不能處理的時候，就使用一定的切分方法，將其變成很多微小的類，然後分門別類地進行處理，以達到最好的效果，最終實現1+1>2的功效。
微服務優點
- 開發簡單：每個服務完成獨立的功能；
- 技術棧靈活：可以選擇不同的語言完成不同的服務，發揮各種語言的最大優勢；
- 服務獨立無依賴：每個服務都可以單獨部署，一個服務出現問題不會導致整個系統癱瘓；
- 獨立按需擴展：以應對高併發與大流量；
- 可用性高：當其中一個點出現問題時，能夠及時切換，不影響業務的正常運行；
- 複雜應用解耦爲小而衆的服務：拆分可以基於一定的原則，將耗時的應用解耦；
- 各服務精而專：也就是我們常說的專人幹專事，映射到微服務中就是專服務幹專事；
- 服務間通信通過API完成：選擇輕量的API通信。微服務的優點和缺點（或者說挑戰）一樣明顯。
微服務缺點
- 多服務運維難度：服務的增加意味着運維的困難，如何有效地管理是一個挑戰；
- 系統部署依賴：當業務複雜時，系統之間的耦合關係高度耦合，如何高效部署是一個挑戰；
- 服務間通信成本：包括網絡延遲、接口不可用性等，保證服務的高可用性是一個挑戰；
- 數據一致性：各個服務間如何有效地共享數據，確保相應服務的數據需求一致性是一個個挑戰；
- 系統集成測試：拆分後，原本需要測試的內容成倍地增加，如何高效地降低測試成本是一個挑戰；
- 重複工作：服務拆分之後，由於信息的不對稱導致的重複性工作，如何有效抽象是一個挑戰；
- 性能監控：原本只需要一個監控的部分，現在需要分開監控，如何快速定位問題是一個挑戰；
- 溝通成本的成倍增加：服務拆分後，各個服務由單獨的人來維護，如何高效地溝通是一個挑戰。
爲什麼微服務
從一般的平臺遇到的問題說起：
- 服務配置複雜。基礎服務多，服務的資源配置複雜。傳統方式管理服務複雜。
- 服務之間調用複雜。檢索服務、用戶中心服務等，服務之間的調用複雜，依賴多。
- 服務監控難度大。服務比較多，機器部署複雜，服務存活監控、業務是否正常監控尤爲重要。
- 服務化測試問題。服務依賴性比較大，測試一個小的功能，周邊服務也需要啓動。
單體架構和分佈式微服務架構的區別
從上面的表格我們可以看到，分佈式系統雖然有一些優勢，但也存在一些問題：
- 架構設計變得複雜(尤其是其中的分佈式事務)；
- 部署單個服務會比較快，但一次部署多個服務會變得複雜；
- 系統的吞吐量會變大，但是響應時間會變長；
- 運維複雜度會因爲服務變多而變得很複雜；
- 架構複雜導致學習曲線變大；
- 測試和查錯的複雜度增大；
- 技術很多樣，帶來維護和運維的複雜度提升；
- 管理分佈式系統中的服務和調度變得困難且複雜。
也就是說，分佈式系統架構的難點在於系統的設計、管理和運維。
隨着服務的拆分，新的問題隨之而來。客戶端如何訪問這些服務?這些服務的調用情況?切分是否合理?是否安全?如果受到攻擊應該如何應對?是否可以使用限流或者降級的方式來及時解決?
應對這些問題，API 網關是一個不錯的解決方案。當有新的設備需要調用這些接口時，可以複用原有接口，不需要進行二次開發。接口的維護也會更有條理性，對於訪問次數、安全等問題，都可以在這一層進行解決，如下圖所示。
解決了應用前端訪問的問題後，服務之間的相互調用也是一個問題， 如果整個系統內部調用關係混亂，就會帶來非常多的不必要的問題。所以約定好服務之間的通信方式是非常有必要的。不管是開源還是公司內部研發，都有非常多的解決方案。最簡單的方式是通過RPC的調用，傳輸JSON或者XML，雙方定義好協議格式，通過報文的方式進行數據傳輸。
當多種服務需要互相調用時，服務的數量會急劇地增加，服務的治理就成爲新的問題，另外還有不同服務的版本問題。如果不能通過一個 單獨的註冊地址，像書的目錄一樣來管理整個服務結構，服務的調用就顯示非常混亂。
一般的分佈式服務都有一個註冊中心，例如，Dubbo 是基於ZooKeeper 進行的二次開發，自身提供管理控制檯，可以對服務進行註冊和查找，Spring Cloud有Eureka,還有etcd、Consul等可供選擇。
經過上面的處理，整體上來看應用已經達到了一個非常好的狀態，但是每個應用服務仍然存在着單點問題，當一個服務出現問題時，有可能導致連鎖的反應，使整個系統癱瘓。這時需要除監控告警外的一種容錯機制來保障整體服務的可運行性。
通過網關層的反向代理來實現高可用是一個不錯的解決方案，訪問層無須瞭解整個體系有多少應用提供，只需要關心服務是否能夠提供服務，並且對必要的接口進行監測即可。當發現接口無法正常提供服務時，提供相應的告警機制，以微信、短信或者郵件的方式通知相關人及時進行處理。
隨着數據量的不斷增長，需要將業務和統計分離。
統計一般都是比較耗時的應用，比如計算用戶的留存情況，需要分析一週甚至是更長週期內的用戶數據，如果使用在線的方式分析顯然不太現實。所以，對於大數據量的分析和數據挖掘，需要從業務中抽取數據進行離線分析，然後將分析的結果進行展現。
微服務的可擴展性
針對以上的分析，可以看到，微服務需要具備極強的可擴展性，這些擴展性包含以下幾個方面。
- 性能可擴展：性能無法完全實現線性擴展，但要儘量使用具有併發性和異步性的組件。具備完成通知功能的工作隊列要優於同步連接到數據庫。
- 可用性可擴展: CAP理論表明，分佈式系統無法同時提供一致性、可用性和分區容錯性保證。許多大規模Web應用程序都爲了可用性和分區容錯性而犧牲了強一致性，而後者則依賴於最終一致性來保證。
- 維護可擴展：軟件和服務器都需要維護。在使用平臺的工具監控和更新應用程序時，要儘可能自動化。
- 成本可擴展：總成本包括開發、維護和運營支出。在設計一個系統時，要在重用現有組件和完全新開發組件之間進行權衡。現有組件很少能完全滿足需求，但修改現有組件的成本還是可能低於開發一個完全不同的方案的。另外，使用符合行業標準的技術使組織更容易聘到專家，而發佈獨有的開源方案則可能幫助組織從社區中挖掘人才。
微服務與SOA的區別
面向服務的架構(SOA) 是一個組件模型，它將應用程序的不同功能單元(稱爲服務)通過這些服務之間定義良好的接口和契約聯繫起來。接口是採用中立的方式進行定義的，它應該獨立於實現服務的硬件平臺、操作系統和編程語言。這使得構建在各種各樣系統中的服務可以以一種統一和通用的方式進行交互。
都是做服務化，那麼微服務與SOA的異同有哪些呢?
相同點
- 需要Registry,實現動態的服務註冊發現機制。
- 需要考慮分佈式下面的事務一致性，CAP原則下，兩段式提交不能保證性能，事務補償機制需要考慮。
- 同步調用還是異步消息傳遞，如何保證消息可靠性?SOA由ESB來集成所有的消息。
- 都需要統一的Gateway來匯聚、編排接口，實現統一認證機制， 對外提供APP使用的RESTful接口。
- 同樣要關注如何在分佈式下定位系統問題，如何做日誌跟蹤?就像電信領域做了十幾年的信令跟蹤的功能。
差異點
- 是持續集成、持續部署?對於CI、CD (持續集成、持續部署)，這本身和敏捷、DevOps是交織在一起的，所以更傾向於軟件工程的領域而不是微服務技術本身。
- 使用不同的通信協議是不是區別?微服務的標杆通信協議是RESTful,而傳統的SOA一般是SOAP，不過目前來說採用輕量級的RPC框架(Dubbo、 Thrift、 gRPC)非常多，在Spring Cloud中也有Feign框架將標準RESTful轉爲代碼的API這種仿RPC的行爲，這些通信協議不應該是區分微服務架構和SOA的核心差別。
- 是流行的基於容器的框架還是虛擬機爲主?Docker虛擬機和物理機都是架構實現的一種方式，不是核心區別。
SOA和微服務的一個主要不同點就是自動化程度上的不同。大部分的SOA實現只達到服務級別的抽象，而微服務達到了對實現和運行環境的抽象級別。
在一個規範的微服務中，每個微服務應該被構建成胖JAR (fat JAR)，其中內置了所有的依賴，然後作爲一個單獨的Java進程存在。
常見的微服務組件
既然談到了微服務架構，下面介紹通用的微服務都包括哪些組件。
- 服務註冊
服務註冊是一個記錄當前可用的微服務實例的網絡信息數據庫，是服務發現機制的主要核心，服務註冊表包含查詢API、管理API,使用查詢API獲得可用服務的實例，使用管理API實現註冊、註銷。
- 服務發現
服務調用方從服務註冊中心找到自己需要調用的服務的地址。可以選擇客戶端服務發現，也可以選擇服務端服務發現。
- 負載均衡
服務提供方一般以多實例的形式提供服務，負載均衡功能能夠讓服務調用方連接到合適的服務節點，並且節點選擇的工作對服務調用方來說是透明的。可以選擇服務端的負載均衡，也可以選擇客戶端的負載均衡。
- 服務網關
服務網關是服務調用的唯一入口，可以在這個組件是實現用戶鑑權、動態路由、灰度發佈、A/B測試、負載限流等功能。根據公司流量規模的大小網關可以是一個，也可以是多個。
- 配置中心
將本地化的配置信息(Properties、 XML、YAML等)註冊到配置中心，實現程序包在開發、測試、生產環境的無差別性，方便程序包的遷移。配置部分可以單獨使用高可用的分佈式配置中心，確保一個配置服務出現問題時，其他服務也能夠提供配置服務。
- API管理
以方便的形式編寫及更新API文檔，並以方便的形式供調用者查看和測試。通常需要加入版本控制的概念，以確保服務的不同版本在升級過程中都能夠提供服務。
- 集成框架
微服務組件都以職責單一的程序包對外提供服務，集成框架以配置的形式將所有微服務組件集成到統一的界面框架下，讓用戶能夠在統一的界面中使用系統。
- 分佈式事務
對於重要的業務，需要通過分佈式事務技術(TCC、高可用消息服務、最大努力通知)保證數據的一致性。根據業務的不同，適當地犧牲一些數據的一致性要求，確保數據的最終一致性。
- 調用鏈
記錄完成一個業務邏輯時調用到的微服務，並將這種串行或並行的調用關係展示出來。在系統出錯時，可以方便地找到出錯點。同時統計各個服務的調用次數，確保比較熱的服務能夠被分配更多的資源。
- 支撐平臺
系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼就需要將大部分的工作自動化。現在，可以通過Docker等工具來中和這些微服務架構帶來的弊端。例如，持續集成、藍綠髮布、健康檢查、性能健康等。可以這麼說，如果沒有合適的支撐平臺或工具，就不要使用微服務架構。
好了，今天就是小編幫大家整理的微服務基礎概念簡述。可能有的朋友覺得特別基礎，確實是，小編整理學習內容都是這樣，由淺及深的層層剖析，爲的就是幫大家夯實基礎，基礎決定上層建築，咱們先把基礎打好，後續會水到渠成~~~
喜歡文章請多多點贊評論分享，關注小編，後續小編會再帶來更多微服務架構和Java學習內容更新，你們的支持就是小編最大的動力~~~