你們好，我是飄渺Jam，一名來自三流城市三流公司的三流程序員，這是咱們的第158篇原創文章，若是你喜歡個人文章請點贊轉發支持一下。 java
什麼是微服務
提到微服務不得不提Martin Fowler在2014年3月25日發表的文章 Microservices，裏面給出了微服務的定義。後續國內全部關於微服務的介紹都是基於這篇文章的翻譯，或加上本身的理解而成。其中最重要的一段以下：程序員
In short, the microservice architectural style [1] is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies.
翻譯過來就是：微服務這種架構風格就是把一組小服務演化成爲一個單一的應用的一種方法。每一個應用都運行在本身的進程中，並經過輕量級的機制保持通訊，就像HTTP這樣的API。這些服務要基於業務場景，並使用自動化佈署工具進行獨立的發佈。能夠有一個很是輕量級的集中式管理來協調這些服務，可使用不一樣的語言來編寫服務，也可使用不一樣的數據存儲。spring
如何實現微服務
相對於單體式架構的簡單粗暴，微服務架構將應用打散，造成多個微服務進行獨立開發、測試、部署與運維。雖然從管理與邏輯上更符合業務須要，但微服務架構也帶來了諸多急需解決的核心問題：服務器
-
如何發現新服務節點以及檢查服務節點的狀態？微信
-
如何發現服務及負載均衡如何實現？架構
-
服務間如何進行消息通訊？app
-
如何對使用者暴露服務 API？負載均衡
-
如何集中管理衆多服務節點的配置文件？框架
-
如何收集服務節點的日誌並統一管理？運維
-
如何實現服務間調用鏈路追蹤？
-
如何對系統進行鏈路保護，避免微服務雪崩？
能夠發現，上述這些問題並非針對某種語言或某種技術的，任何軟件廠商要構建微服務架構就必須面對這些問題，要麼獨立開發要麼將已有多種技術整合造成總體解決方案。好在通過多年沉澱，業內已經有了標準答案，下圖清晰的說明微服務架構須要的標準組件。
API網關： 封裝了系統內部架構，爲每一個客戶端提供一個定製的 API。在微服務架構中，服務網關的核心要點是，全部的客戶端和消費端都經過統一的網關接入微服務，在網關層處理全部的非業務功能。
註冊中心： 微服務架構體系中最核心的技術組件，它起到新服務節點的註冊與狀態維護的做用。諸如 Dubbo、Spring Cloud 等主流的微服務框架都基於 Zookeeper、Eureka 等分佈式系統協調工具構建了服務註冊中心。
服務路由： 經過註冊中心構建了一個多服務的集羣化環境中，當客戶端請求到達集羣，如何肯定由哪一臺服務器進行請求響應呢？這就是服務路由問題。
服務通訊： 在微服務定義中闡述服務間通訊採用輕量級協議，一般是 HTTP RESTful 風格。但因 RESTful 風格過於靈活，必須加以約束，一般在應用時對其進行上層封裝，例如在 Spring Cloud 中就提供了 Feign 和 RestTemplate 兩種技術屏蔽底層實現 RESTful 通訊細節。
服務保護： 對於分佈式環境中的服務而言，服務在自身失敗引起生錯誤的同時，還會由於依賴其餘服務而致使失敗。除了比較容易想到和實現的超時、重試和異步解耦等手段以外，咱們須要考慮針對各類場景的容錯機制。
鏈路跟蹤：一個複雜的業務流程可能須要連續調用多個微服務，咱們須要記錄一個完整業務邏輯涉及的每個微服務的運行狀態，再經過可視化鏈路圖展示，幫助軟件工程師在系統出錯時分析解決問題，常見的解決方案有Zipkin，SkyWalking。
統一日誌管理： 微服務架構默認將應用日誌分散保存在每個微服務節點上，當系統進行用戶行爲分析、數據統計時必須收集全部節點日誌數據，很是不方便。這時候咱們須要一個獨立的日誌平臺，收集全部節點的日誌數據並可方便對其進行彙總分析，常見的解決方案有ELK，EFK。
配置中心： 在微服務架構中，考慮到服務數量和配置信息的分散性，通常都須要引入配置中心的設計思想和相關工具。經過部署配置中心服務器，將本來分散的配置文件從應用中剝離，集中轉存到配置中心。通常配置中心會提供 UI 界面，能夠方便快捷的實現大規模集羣的配置調整。
爲何選擇SpringCloud
首先，Spring Cloud 具有一個天生的優點，由於它是 Spring 家庭的一員，而 Spring 在 Java EE 開發領域的強大地位，給 Spring Cloud 起到很好的推進做用。同時，Spring Cloud 所基於的 Spring Boot，已經成爲 Java EE 領域中最流行的開發框架，用來簡化 Spring 應用程序的框架搭建和開發過程。
其次，技術組件的完備性是咱們選擇 Spring Cloud 的主要緣由。Spring Cloud 中包含了開發一個完整的微服務系統所需的幾乎全部技術組件，包括服務註冊和發現、API 網關、配置中心、消息處理、負載均衡、熔斷器、數據監控等常見技術組件均可以基於 Spring Boot 快速集成到業務系統中。
如下爲SpringCloud 中經常使用的技術組件
爲何選擇SpringCloud alibaba
首先， SpringCloud中的技術組件是集衆家之長，如註冊中心 Eureka，Zuul等都是依賴於Netflix的，這也致使它受制於第三方廠商。如Zuul宣佈中止維護，Spring機構便不得不尋找替代品或自研；Eureka2.x 閉源不容許使用；
其次，Springcloud做爲國外產品引入到國內後出現了水土不服，如SpringCloud Config默認將文件存在Github上，且沒有維護界面，國內軟件公司不多會贊成這麼作。好比咱們部門就是使用了Apollo配置中心替代了原生的SpringCloud Config。
Spring Cloud Alibaba是國產的微服務開發一站式解決方案，與原有 Spring Cloud 兼容的同時對微服務生態進行擴展，經過添加少許的配置註解，即可實現更符合國情的微服務架構，當前Spring Cloud Alibaba已是直接隸屬於 Spring Cloud 的子項目。官網是：https://spring.io/projects/spring-cloud-alibaba#overview
Spring Cloud Alibaba 對服務註冊、配置中心與負載均衡功能都整合進 Nacos，有圖形化界面，簡化了微服務架構的複雜度，出問題的機率也會下降。原有的服務保護組件也調整爲 Sentinel，相較Hystrix功能更強大，使用也更加友好。同時還支持了對Dubbo的調用，並且還有Seata用於支持分佈式事務。
本文分享自微信公衆號 - JAVA日知錄（javadaily）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。