廬山真面目之一微服務的簡介和技術棧

微服務的簡介和技術棧

1、簡介
         這些年軟件的設計規模愈來愈龐大，業務需求也愈來愈複雜，針對系統的性能、高吞吐率、高穩定性、高擴展等特性提出了更高的要求。能夠說業務需求是軟件架構能力的第一推進力，因爲這些因素致使了軟件架構思想和相關技術也在發生着鉅變。這些變化反應在軟件架構行業裏，就是咱們開始愈來愈多的聽到了不少新的詞彙，好比：「分佈式」、「SOA」、「微服務」、「中臺」等概念。
        今天我就把我學習微服務的過程記錄下來，包括全部技術的實現細節和我的的理解。俗話說：好記性，不如爛筆頭，以防本身忘記，之後能夠查詢。固然，這些東西有不少東西都是本身的理解，裏面的插圖也是本身畫的，可能會有一些有失偏頗的地方，固然但願有高手能夠指正，不靈賜教，你們共同進步。

2、架構發展歷程
         如今的科學技術能夠說是突飛猛進，發展迅速。相對於咱們軟件設計行業也在發生着鉅變，業務愈來愈複雜，需求愈來愈龐大、繁雜，軟件架構和部署的規模也發生着翻天覆地的變化，做爲軟件架構思想之一的「微服務架構」也在按着本身的規律進化着，接下來咱們就簡單的瞭解一下「微服務架構」發展經歷的三個時期，這些只是我的理解。

       1、單體架構（Monolithic）
             單體應用時代：應用程序不管如何分層，都是一個解決方案，或者說都是一個項目，這裏的「解決方案」和「項目」不是咱們使用的 Visual Studio裏面的概念，最終的程序代碼都會在一個進程裏運行。
             如圖：
                  
            優勢：開發簡單，集中管理，沒有分佈式的損耗，都是系統進程內的通訊。
            缺點：很差維護，升級困難，耦合嚴重，沒法應付高併發和大數據場景，沒法快捷迭代。
                     （1）、只能採用同一種技術，很難用不一樣的語言或者相同語言不一樣版本開發不一樣模塊。
                     （2）、系統耦合性太強，其中一個模塊有問題，這個系統就會癱瘓，一個模塊升級，整個系統就得停機維護。
                     （3）、要上線，必須一塊兒上線，互相等待，沒法快速相應市場需求。
                     （4）、集羣負擔大，若是想要集羣，只能對整個系統進行集羣，即便一個模塊有壓力。

       2、垂直拆分
             隨着業務規模的愈來愈龐大，系統設計就愈來愈複雜，大的系統就開始進行業務的垂直拆分。好比：有專門作商品秒殺的部門，有專門作生鮮商品的部門，有專門作超市的部門，等等，固然這是根據部門天生劃分的，也有根據業務需求進行系統劃分的。
             如圖：
                  
             優勢：垂直拆分，系統獨立部署和維護，每一個系統在本身進程內執行，分而治之。
             缺點：拆分越多，存儲越複雜，系統間重複的東西也越多，單個系統仍是單體模式。

        3、分佈式服務
            隨着業務系統的愈來愈龐大，軟件系統設計起來愈來愈複雜。爲了不過分複雜的業務需求，開始對業務系統的進行垂直拆分，造成多個獨立的業務系統，若是多個系統之間要通訊，能夠經過跨進程的技術完成通信。可是垂直拆分也致使了大量重複代碼、重複模塊的產生，好比：用戶模塊、日誌模塊、支付模塊、認證受權模塊等，這樣分散的代碼也給系統的維護和升級帶來了困難。咱們對業務從新劃分，把獨立的模塊接口化、服務化，提升重用，這個時候，咱們就開始進入了分佈式服務的時代。（分佈式的第一要務就是不要分佈式）
           如圖：
                  
           優勢：
                 一、獨立進程部署，獨立進程運行，獨立演化。服務之間能夠作到高內聚，低耦合。
                 二、獨立開發和維護，業務解耦，不管是業務系統仍是分佈式服務都獨立演化。
                 三、分佈式管理
                 四、隔離性加強
                 五、由一系列服務組裝成系統，不用重複建設，模塊、代碼能夠複用。
          缺點：
                一、數據一致性（多服務完成一個任務）和系統的可用性（集羣）成爲問題
                二、數據庫也進行了拆分。
                三、維護、設計、架構成本增長，調試、糾錯更難。
                四、網絡傳輸分佈式損耗成本
                五、不適合高併發和大數據的環境。

         4、微服務架構
                微服務的出現時分佈式架構已經很成熟了，架構中各類問題已經有了很成熟的解決方案，對於如今的業務系統來講，分佈式架構已經變成了一種常規手段，這個時候，微服務就出現了。微服務架構是一個用分佈式服務拆分業務邏輯，完成解耦的架構模式（架構風格）。微服務確定是分佈式的一種，是在分佈式技術成熟以後，而後把分佈式當成解耦手段來架構系統-----由於拆分的服務很細緻，服務數量規模開始變多了，服務的體量開始縮小了，由之前幾個大的服務，轉變爲多個獨立運行的、原子性質的服務。

                如圖：
                      

                微服務最重要的特性是：
                      （1）、可用性：描述一個系統在一段時間內提供有用資源的能力，從而減小停工時間，而保持其服務的高度可用性。         
                      （2）、伸縮性：根據需求動態添加和刪除系統中資源的能力，是水平或垂直擴展的專門實現。
                 集羣（負載均衡）能夠解決系統的高可用和伸縮特性。

                優勢：
       　　       （1）、可使用不一樣語言或者相同語言的不一樣版本開發各個模塊。
　　              （2）、系統耦合性低，各個模塊分而治之，獨立部署，獨立發佈，獨立維護。
    　　          （3）、能夠更快的相應市場的需求，更符合敏捷開發。
　　　          （4）、能夠對不一樣模塊使用集羣策略，哪裏有問題治哪裏。
　　　　   缺點：
  　　　　     （1）、開發難度更大，系統結構更復雜。
       　　　　（2）、運行效率低，網絡調用成本很大。

            5、SOA 面向服務架構
                  Service-Oriented Architecture 面向服務架構：是一個組件模型，它將應用程序的不一樣功能單元（稱爲服務）進行拆分，並經過這些服務之間定義良好的接口和協議聯繫起來。
                  如圖：
                       
    

3、微服務架構的發展歷程

           咱們要解決微服務的高可用和可伸縮的兩個問題，天然就會想到經過集羣來實現，這個思路沒有錯。若是咱們實現了服務集羣，那另外兩個問題就會出現，這兩個問題也致使了微服務架構的發展版本的差別。第一個：服務的發現問題，調用方如何發現服務，有了新的服務，咱們如何知道，有服務實例掉線，咱們如何曉得，發現服務就很重要，這個是基礎問題，第一個問題不解決，第二個問題也沒有辦法實現；第二個：如何調用服務，如何管理那麼多的服務實例。有那麼多的集羣實例，也就有那麼多的服務實例，咱們該怎麼去調用這些服務呢？多個服務調用的關係如何呢？
          因爲這些問題，那咱們就看看微服務架構的三個版本是如何解決的。

           1、集中式代理----Nginx（V1.0 版本（服務註冊/服務發現----手動））

                   
               （1）、服務發現，手動修改配置文件，從新啓動。
               （2）、負載均衡，能夠輪訓、權重、哈希等等。
               （3）、服務新增沒法發現，須要手動配置，服務掉線能夠自動檢查。
               （4）、客戶端的實現很簡單，不須要額外的代碼，簡單，高效。

           2、客戶端嵌入----Consul（V2.0版本（服務註冊/服務發現—自動---服務治理））
               
               （1）、服務註冊與發現，動態增長，自動完成。
               （2）、健康檢查，能夠查看損壞服務，去掉服務，自動完成。
               （3）、負載均衡，Consul 返回全部活動服務實例，客戶端本身實現負載均衡。

                  功能強大，自動發現-自動下線，客戶端集成比較複雜，負載均衡在客戶端實現。

           3、服務網格-Service Mesh（V3.0---技術不成熟，華爲+惟品會，lstio）
                
                 SideCar服務管理服務實例的註冊和發現，服務實例的治理和調用。Service Mesh’s Control Plan 管理全部的 SideCar。這個技術我就很少談了，網上的資料也不少，目前這個技術還不是很成熟，使用的範圍也不是很廣，只有一些大的公司有過使用，好比：微軟等。

                

4、微服務架構必備技術棧
           微服務是一種軟件設計、架構思想，固然，裏面也包含了相關技術點要解決當前要務。學習微服務，咱們不能空口而談，必定要落實到具體的技術棧上。當今使用比較多兩個技術體系，一個是Java，另一個就是Net，廢話很少說，我是使用微軟相關技術棧的軟件架構人員，固然使用的「微服務」架構技術棧也都是微軟的。今天我就把相關「微服務架構」所用到的技術棧羅列出來，我也要說明一下，微服務架構裏面的不少技術是和開發語言無關的，不管是 .Net 仍是 Java 平臺均可以使用。之後，一步一步的針對每項技術在作深刻研究。

          1、微服務架構----服務通訊
                WebService、WCF、WebAPI，甚至能夠是 ASHX,ASPX，這都是微軟自己的技術體系，沒什麼可說的。
                 （1）、主動觸發
                 （2）、數據序列化傳遞
                 （3）、跨平臺。
                 （4）、跨語言
                 （5）、Http 穿透防火牆。

         2、微服務架構----進程通訊
                （1）、Net Remoting：Net 平臺督郵的，不支持跨平臺。
                （2）、gRPC：高性能、開源和通用 RPC框架，面向服務端和移動端，基於 HTTP/2 設計，推薦使用。

         三、微服務架構---API網關服務（Ocelot）
                 
                  API網關—— 它是系統的暴露在外部的一個訪問入口。這個有點像代理訪問的傢伙，就像一個公司的門衛承擔着尋址、限制進入、安全檢查、位置引導、等等功能。Ocelot是一個用.NET Core實現而且開源的API網關，它功能強大，包括了：路由、請求聚合、服務發現、認證、鑑權、限流熔斷、並內置了負載均衡器與Service Fabric、Butterfly Tracing集成。這些功能只都只須要簡單的配置便可完成。
                  如圖：
                       
              官網：https://ocelot.readthedocs.io/en/latest/index.html

         4、微服務架構—認證&受權

              
               如今的應用開發層出不窮，基於瀏覽器的網頁應用，基於微信的公衆號、小程序，基於IOS、Android的App，基於Windows系統的桌面應用和UWP應用等等，這麼多種類的應用，就給應用的開發帶來的挑戰，咱們除了分別實現各個應用外，咱們還要考慮各個應用之間的交互，通用模塊的提煉，其中身份的認證和受權就是每一個應用必不可少的的一部分。而如今的互聯網，對於信息安全要求又十分苛刻，因此一套統一的身份認證和受權就相當重要。

IdentityServer4就是這樣一個框架，IdentityServer4是爲ASP.NET CORE量身定製的實現了OpenId Connect和OAuth2.0協議的認證受權中間件。

              項目地址：https://github.com/IdentityServer/IdentityServer4

         五、微服務架構—瞬態故障處理
               
                Polly它一款強大的類庫，Polly是一種.NET彈性和瞬態故障處理庫，容許咱們以很是順暢和線程安全的方式來執諸如行重試，斷路，超時，故障恢復等策略。 Polly針對 .NET 4.0，.NET 4.5和.NET Standard 1.1以及.NET Core實現，該項目做者現已成爲.NET基金會一員，項目一直在不停迭代和更新，你值得擁有。
                項目地址： https://github.com/App-vNext/Polly

       6、微服務架構----分佈式追蹤
             
                隨着微服務架構的流行，一些微服務架構下的問題也會愈來愈突出，好比一個請求會涉及多個服務，而服務自己可能也會依賴其餘服務，整個請求路徑就構成了一個網狀的調用鏈，而在整個調用鏈中一旦某個節點發生異常，整個調用鏈的穩定性就會受到影響，因此會深深的感覺到 「銀彈」 這個詞是不存在的，每種架構都有其優缺點 。
                     

                面對以上狀況， 咱們就須要一些能夠幫助理解系統行爲、用於分析性能問題的工具，以便發生故障的時候，可以快速定位和解決問題，這時候 APM（應用性能管理）工具就該閃亮登場了。
                項目地址：https://github.com/SkyAPM/SkyAPM-dotnet

        7、微服務架構----分佈式日誌

                 通常咱們須要進行日誌分析場景：直接在日誌文件中 grep、awk 就能夠得到本身想要的信息。但在規模較大也就是日誌量多而複雜的場景中，此方法效率低下，面臨問題包括日誌量太大如何歸檔、文本搜索太慢怎麼辦、如何多維度查詢。須要集中化的日誌管理，全部服務器上的日誌收集彙總。常看法決思路是創建集中式日誌收集系統，將全部節點上的日誌統一收集，管理，訪問。

                  大型系統一般都是一個分佈式部署的架構，不一樣的服務模塊部署在不一樣的服務器上，問題出現時，大部分狀況須要根據問題暴露的關鍵信息，定位到具體的服務器和服務模塊，構建一套集中式日誌系統，能夠提升定位問題的效率。

                 （1）、Exceptionless 是一個開源的實時的日誌收集框架，它能夠應用在基於 ASP.NET，ASP.NET Core，Web Api，Web Forms，WPF，Console，MVC 等技術棧的應用程序中，而且提供了Rest接口能夠應用在 Javascript，Node.js 中。它將日誌收集變得簡單易用而且不須要了解太多的相關技術細節及配置。在之前，咱們作日誌收集大多使用 Log4net，Nlog 等框架，在應用程序變得複雜而且集羣的時候，可能傳統的方式已經不是很好的適用了，由於收集各個日誌而且分析他們將變得麻煩並且浪費時間。

                           如今Exceptionless團隊給咱們提供了一個更好的框架來作這件事情，我認爲這是很是偉大而且有意義的，感謝他們。
                         

                           官網：http://exceptionless.com/

                           GitHub：https://github.com/exceptionless/Exceptionless

                （2）、ELK是三個開源軟件的縮寫，分別爲：Elasticsearch 、 Logstash以及Kibana , 它們都是開源軟件。不過如今還新增了一個Beats，它是一個輕量級的日誌收集處理工具(Agent)，Beats佔用資源少，適合於在各個服務器上搜集日誌後傳輸給Logstash，官方也推薦此工具，目前因爲本來的ELK Stack成員中加入了 Beats 工具因此已更名爲Elastic Stack。推薦使用。
                        

        8、微服務架構----分佈式配置中心
              
                Apollo（阿波羅）是攜程框架部門研發的配置管理平臺，可以集中化管理應用不一樣環境、不一樣集羣的配置，配置修改後可以實時推送到應用端，而且具有規範的權限、流程治理等特性。

                服務端基於 Spring Boot 和 Spring Cloud 開發，打包後能夠直接運行，不須要額外安裝 Tomcat 等應用容器。

                Java 客戶端不依賴任何框架，可以運行於全部 Java 運行時環境，同時對 Spring 環境也有較好的支持。

              .Net 客戶端不依賴任何框架，可以運行於全部 .Net 運行時環境。

               項目地址：https://github.com/ctripcorp/apollo/

       9、微服務架構----分佈式鎖
              分佈式鎖的解決方案有不少，我在這裏就羅列一些，我會在之後的實踐中實現這些技術點。
              （1）、Consul 能夠實現分佈式鎖
              （2）、Redis 能夠實現分佈式鎖，推薦使用。
              （3）、Zookeeper 能夠實現分佈式鎖
              （4）、數據庫 能夠實現分佈式鎖
       
       10、微服務架構----分佈式事務
              分佈式事務的實現方式也很多，之後努力學習吧。
              （1）、2PC（two-phase commit protocol，強一致性，沒有可用性）
              （2）、3PC
              （3）、TCC（Try-Confirm-Cancel）
              （4）、本地消息表，推薦 RabbitMQ。
              （5）、Saga 模式

              本地消息表：MQ分佈式事務—本地消息表—基於消息的一致性。
             （1）、上有投遞消息
             （2）、下游獲取消息
             （3）、上游投遞穩定性
             （4）、下游接受穩定性

        11、微服務架構—容器化

               
                Docker 是一個開源的應用容器引擎，能夠打包應用以及依賴包到一個可移植的鏡像中，而後發佈到任何流行的 Linux 和Windows 機器上，也能夠實現虛擬化。

                Docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程API來管理和建立Docker容器。Docker 容器經過 Docker 鏡像來建立。容器與鏡像的關係相似於面向對象編程中的對象與類。

                Docker採用 C/S架構 Docker daemon 做爲服務端接受來自客戶的請求，並處理這些請求（建立、運行、分發容器）。 客戶端和服務端既能夠運行在一個機器上，也可經過 socket 或者RESTful API 來進行通訊。

                Docker daemon 通常在宿主主機後臺運行，等待接收來自客戶端的消息。 Docker 客戶端則爲用戶提供一系列可執行命令，用戶用這些命令實現跟 Docker daemon 交互。

                 如圖：
                      

          12、微服務架構—容器編排

                
                  Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，一般要部署該應用的多個實例以便對應用請求進行負載均衡。

                  在Kubernetes中，咱們能夠建立多個容器，每一個容器裏面運行一個應用實例，而後經過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不須要運維人員去進行復雜的手工配置和處理。

                  Kubernetes 也能夠理解爲Docker 的編排容器，是管理應用的全生命週期的工具，從建立應用/部署，應用提供服務，擴容縮容，更新，都很是的方便，並且能夠作到故障自愈

                 中文社區：http://docs.kubernetes.org.cn/

                 官網：https://kubernetes.io/docs/home/

           13、微服務架構—CI/CD

                  
                   Jenkins 是一個開源的、提供友好操做界面的持續集成（CI）工具，主要用於持續、自動的構建/測試軟件項目、監控外部任務的運行。

                  官網: http://www.jenkins.org.cn/

5、 結束語

           好了，今天就寫到這裏了，今天仍是寫了很多東西，今天沒別的，就是作一下相關技術棧的記錄，之後有時間，再把每項技術仔細研究，多是每項技術，也多是以一個項目來研究，這個項目中可能包含不少其餘的技術，到時候，再決定。天天進步一點，加油。