老板下了死命令，要上微服務(wù)！

你知道的越多，不知道的就越多，業(yè)余的像一棵小草！

你來，我們一起精進！你不來，我和你的競爭對手一起精進！

編輯：業(yè)余草

cnblogs.com/PatrickLiu

推薦：https://www.xttblog.com/?p=5162

這些年軟件的設(shè)計規(guī)模越來越龐大，業(yè)務(wù)需求也越來越復(fù)雜，針對系統(tǒng)的性能、高吞吐率、高穩(wěn)定性、高擴展等特性提出了更高的要求。

可以說業(yè)務(wù)需求是軟件架構(gòu)能力的第一推動力，由于這些因素導(dǎo)致了軟件架構(gòu)思想和相關(guān)技術(shù)也在發(fā)生著巨變。

這些變化反應(yīng)在軟件架構(gòu)行業(yè)里，就是我們開始越來越多的聽到了很多新的詞匯，比如：“分布式”、“SOA”、“微服務(wù)”、“中臺”等概念。

今天我就把我學(xué)習微服務(wù)的過程記錄下來，包括所有技術(shù)的實現(xiàn)細節(jié)和個人的理解。俗話說：好記性，不如爛筆頭，以防自己忘記，以后可以查詢。

當然，這些東西有很多東西都是自己的理解，里面的插圖也是自己畫的，可能會有一些有失偏頗的地方，當然希望有高手可以指正，不靈賜教，大家共同進步。

現(xiàn)在的科學(xué)技術(shù)可以說是日新月異，發(fā)展迅速。相對于我們軟件設(shè)計行業(yè)也在發(fā)生著巨變，業(yè)務(wù)越來越復(fù)雜，需求越來越龐大、繁雜，軟件架構(gòu)和部署的規(guī)模也發(fā)生著翻天覆地的變化。

作為軟件架構(gòu)思想之一的“微服務(wù)架構(gòu)”也在按著自己的規(guī)律進化著，接下來我們就簡單的了解一下“微服務(wù)架構(gòu)”發(fā)展經(jīng)歷的三個時期，這些只是個人理解。

單體應(yīng)用時代：應(yīng)用程序無論如何分層，都是一個解決方案，或者說都是一個項目，這里的“解決方案”和“項目”不是我們使用的 Visual Studio 里面的概念，最終的程序代碼都會在一個進程里運行。

如圖：

優(yōu)點：開發(fā)簡單，集中管理，沒有分布式的損耗，都是系統(tǒng)進程內(nèi)的通信。

缺點：不好維護，升級困難，耦合嚴重，無法應(yīng)付高并發(fā)和大數(shù)據(jù)場景，無法快捷迭代。

隨著業(yè)務(wù)規(guī)模的越來越龐大，系統(tǒng)設(shè)計就越來越復(fù)雜，大的系統(tǒng)就開始進行業(yè)務(wù)的垂直拆分。

比如：有專門做商品秒殺的部門，有專門做生鮮商品的部門，有專門做超市的部門，等等，當然這是根據(jù)部門天生劃分的，也有根據(jù)業(yè)務(wù)需求進行系統(tǒng)劃分的。

優(yōu)點：垂直拆分，系統(tǒng)獨立部署和維護，每個系統(tǒng)在自己進程內(nèi)執(zhí)行，分而治之。

缺點：拆分越多，存儲越復(fù)雜，系統(tǒng)間重復(fù)的東西也越多，單個系統(tǒng)還是單體模式。

隨著業(yè)務(wù)系統(tǒng)的越來越龐大，軟件系統(tǒng)設(shè)計起來越來越復(fù)雜。為了避免過度復(fù)雜的業(yè)務(wù)需求，開始對業(yè)務(wù)系統(tǒng)的進行垂直拆分，形成多個獨立的業(yè)務(wù)系統(tǒng)，如果多個系統(tǒng)之間要通信，可以通過跨進程的技術(shù)完成通訊。

但是垂直拆分也導(dǎo)致了大量重復(fù)代碼、重復(fù)模塊的產(chǎn)生，比如：用戶模塊、日志模塊、支付模塊、認證授權(quán)模塊等，這樣分散的代碼也給系統(tǒng)的維護和升級帶來了困難。

我們對業(yè)務(wù)重新劃分，把獨立的模塊接口化、服務(wù)化，提高重用，這個時候，我們就開始進入了分布式服務(wù)的時代。（分布式的第一要務(wù)就是不要分布式）

如圖：

優(yōu)點：

• 獨立進程部署，獨立進程運行，獨立演化。服務(wù)之間可以做到高內(nèi)聚，低耦合。
  

• 獨立開發(fā)和維護，業(yè)務(wù)解耦，無論是業(yè)務(wù)系統(tǒng)還是分布式服務(wù)都獨立演化。
  

• 分布式管理。
  

• 隔離性增強。
  

• 由一系列服務(wù)組裝成系統(tǒng)，不用重復(fù)建設(shè)，模塊、代碼可以復(fù)用。
  

缺點：

• 數(shù)據(jù)一致性（多服務(wù)完成一個任務(wù)）和系統(tǒng)的可用性（集群）成為問題。
  

• 數(shù)據(jù)庫也進行了拆分。
  

• 維護、設(shè)計、架構(gòu)成本增加，調(diào)試、糾錯更難。
  

• 網(wǎng)絡(luò)傳輸分布式損耗成本。
  

• 不適合高并發(fā)和大數(shù)據(jù)的環(huán)境。
  

微服務(wù)的出現(xiàn)時分布式架構(gòu)已經(jīng)很成熟了，架構(gòu)中各種問題已經(jīng)有了很成熟的解決方案，對于現(xiàn)在的業(yè)務(wù)系統(tǒng)來說，分布式架構(gòu)已經(jīng)變成了一種常規(guī)手段，這個時候，微服務(wù)就出現(xiàn)了。

微服務(wù)架構(gòu)是一個用分布式服務(wù)拆分業(yè)務(wù)邏輯，完成解耦的架構(gòu)模式（架構(gòu)風格）。

微服務(wù)肯定是分布式的一種，是在分布式技術(shù)成熟之后，然后把分布式當成解耦手段來架構(gòu)系統(tǒng)。

因為拆分的服務(wù)很細致，服務(wù)數(shù)量規(guī)模開始變多了，服務(wù)的體量開始縮小了，由以前幾個大的服務(wù)，轉(zhuǎn)變?yōu)槎鄠€獨立運行的、原子性質(zhì)的服務(wù)。

微服務(wù)最重要的特性是：

• 可用性：描述一個系統(tǒng)在一段時間內(nèi)提供有用資源的能力，從而減少停工時間，而保持其服務(wù)的高度可用性。
  

• 伸縮性：根據(jù)需求動態(tài)添加和刪除系統(tǒng)中資源的能力，是水平或垂直擴展的專門實現(xiàn)。

集群（負載均衡）可以解決系統(tǒng)的高可用和伸縮特性。

Service-Oriented Architecture 面向服務(wù)架構(gòu)：是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）進行拆分，并通過這些服務(wù)之間定義良好的接口和協(xié)議聯(lián)系起來。

我們要解決微服務(wù)的高可用和可伸縮的兩個問題，自然就會想到通過集群來實現(xiàn)，這個思路沒有錯。

如果我們實現(xiàn)了服務(wù)集群，那另外兩個問題就會出現(xiàn)，這兩個問題也導(dǎo)致了微服務(wù)架構(gòu)的發(fā)展版本的差異。

第一個：服務(wù)的發(fā)現(xiàn)問題，調(diào)用方如何發(fā)現(xiàn)服務(wù)，有了新的服務(wù)，我們?nèi)绾沃溃蟹?wù)實例掉線，我們?nèi)绾螘缘?，發(fā)現(xiàn)服務(wù)就很重要，這個是基礎(chǔ)問題，第一個問題不解決，第二個問題也沒有辦法實現(xiàn)。

第二個：如何調(diào)用服務(wù)，如何管理那么多的服務(wù)實例。有那么多的集群實例，也就有那么多的服務(wù)實例，我們該怎么去調(diào)用這些服務(wù)呢？多個服務(wù)調(diào)用的關(guān)系如何呢？

由于這些問題，那我們就看看微服務(wù)架構(gòu)的三個版本是如何解決的。

如上圖：

• 服務(wù)發(fā)現(xiàn)，手動修改配置文件，重新啟動。
  

• 負載均衡，可以輪訓(xùn)、權(quán)重、哈希等等。
  

• 服務(wù)新增無法發(fā)現(xiàn)，需要手動配置，服務(wù)掉線可以自動檢查。
  

• 客戶端的實現(xiàn)很簡單，不需要額外的代碼，簡單，高效。

如上圖：

• 服務(wù)注冊與發(fā)現(xiàn)，動態(tài)增加，自動完成。
  

• 健康檢查，可以查看損壞服務(wù)，去掉服務(wù)，自動完成。
  

• 負載均衡，Consul 返回所有活動服務(wù)實例，客戶端自己實現(xiàn)負載均衡。

功能強大，自動發(fā)現(xiàn)-自動下線，客戶端集成比較復(fù)雜，負載均衡在客戶端實現(xiàn)。

SideCar 服務(wù)管理服務(wù)實例的注冊和發(fā)現(xiàn)，服務(wù)實例的治理和調(diào)用。Service Mesh’s Control Plan 管理所有的 SideCar。

微服務(wù)是一種軟件設(shè)計、架構(gòu)思想，當然，里面也包含了相關(guān)技術(shù)點要解決當前要務(wù)。學(xué)習微服務(wù)，我們不能空口而談，一定要落實到具體的技術(shù)棧上。

當今使用比較多兩個技術(shù)體系，一個是 Java，另外一個就是 Net，廢話不多說，我是使用微軟相關(guān)技術(shù)棧的軟件架構(gòu)人員，當然使用的“微服務(wù)”架構(gòu)技術(shù)棧也都是微軟的。

今天我就把相關(guān)“微服務(wù)架構(gòu)”所用到的技術(shù)棧羅列出來，我也要說明一下，微服務(wù)架構(gòu)里面的很多技術(shù)是和開發(fā)語言無關(guān)的，無論是 .Net 還是 Java 平臺都可以使用。以后，一步一步的針對每項技術(shù)在做深入研究。

①服務(wù)通信

WebService、WCF、WebAPI，甚至可以是 ASHX，ASPX，這都是微軟本身的技術(shù)體系，沒什么可說的：

• 主動觸發(fā)
  

• 數(shù)據(jù)序列化傳遞
  

• 跨平臺
  

• 跨語言
  

• Http 穿透防火墻

②進程通信

Net Remoting：Net 平臺督郵的，不支持跨平臺。

gRPC：高性能、開源和通用 RPC 框架，面向服務(wù)端和移動端，基于 HTTP/2 設(shè)計，推薦使用。

API 網(wǎng)關(guān)：它是系統(tǒng)的暴露在外部的一個訪問入口。這個有點像代理訪問的家伙，就像一個公司的門衛(wèi)承擔著尋址、限制進入、安全檢查、位置引導(dǎo)、等等功能。

Ocelot 是一個用 .NET Core 實現(xiàn)并且開源的 API 網(wǎng)關(guān)，它功能強大，包括了：路由、請求聚合、服務(wù)發(fā)現(xiàn)、認證、鑒權(quán)、限流熔斷。

并內(nèi)置了負載均衡器與 Service Fabric、Butterfly Tracing 集成。這些功能只都只需要簡單的配置即可完成。

https://ocelot.readthedocs.io/en/latest/index.html

現(xiàn)在的應(yīng)用開發(fā)層出不窮，基于瀏覽器的網(wǎng)頁應(yīng)用，基于微信的公眾號、小程序，基于 iOS、Android 的 App，基于 Windows 系統(tǒng)的桌面應(yīng)用和 UWP 應(yīng)用等等。

這么多種類的應(yīng)用，就給應(yīng)用的開發(fā)帶來的挑戰(zhàn)，我們除了分別實現(xiàn)各個應(yīng)用外，我們還要考慮各個應(yīng)用之間的交互，通用模塊的提煉，其中身份的認證和授權(quán)就是每個應(yīng)用必不可少的的一部分。

而現(xiàn)在的互聯(lián)網(wǎng)，對于信息安全要求又十分苛刻，所以一套統(tǒng)一的身份認證和授權(quán)就至關(guān)重要。

IdentityServer4 就是這樣一個框架，IdentityServer4 是為 ASP.NET CORE 量身定制的實現(xiàn)了 OpenId Connect 和 OAuth2.0 協(xié)議的認證授權(quán)中間件。

https://github.com/IdentityServer/IdentityServer4

Polly 它一款強大的類庫，Polly 是一種 .NET 彈性和瞬態(tài)故障處理庫，允許我們以非常順暢和線程安全的方式來執(zhí)諸如行重試，斷路，超時，故障恢復(fù)等策略。

Polly 針對 .NET 4.0，.NET 4.5 和 .NET Standard 1.1 以及 .NET Core 實現(xiàn)，該項目作者現(xiàn)已成為 .NET 基金會一員，項目一直在不停迭代和更新，你值得擁有。

https://github.com/App-vNext/Polly

隨著微服務(wù)架構(gòu)的流行，一些微服務(wù)架構(gòu)下的問題也會越來越突出，比如一個請求會涉及多個服務(wù)，而服務(wù)本身可能也會依賴其他服務(wù)，整個請求路徑就構(gòu)成了一個網(wǎng)狀的調(diào)用鏈。

面對以上情況， 我們就需要一些可以幫助理解系統(tǒng)行為、用于分析性能問題的工具，以便發(fā)生故障的時候，能夠快速定位和解決問題，這時候 APM（應(yīng)用性能管理）工具就該閃亮登場了。

項目地址：

https://github.com/SkyAPM/SkyAPM-dotnet

⑦分布式日志

一般我們需要進行日志分析場景：直接在日志文件中 grep、awk 就可以獲得自己想要的信息。

但在規(guī)模較大也就是日志量多而復(fù)雜的場景中，此方法效率低下，面臨問題包括日志量太大如何歸檔、文本搜索太慢怎么辦、如何多維度查詢。

需要集中化的日志管理，所有服務(wù)器上的日志收集匯總。常見解決思路是建立集中式日志收集系統(tǒng)，將所有節(jié)點上的日志統(tǒng)一收集，管理，訪問。

大型系統(tǒng)通常都是一個分布式部署的架構(gòu)，不同的服務(wù)模塊部署在不同的服務(wù)器上，問題出現(xiàn)時，大部分情況需要根據(jù)問題暴露的關(guān)鍵信息，定位到具體的服務(wù)器和服務(wù)模塊，構(gòu)建一套集中式日志系統(tǒng)，可以提高定位問題的效率。

Exceptionless：是一個開源的實時的日志收集框架，它可以應(yīng)用在基于 ASP.NET，ASP.NET Core，Web Api，Web Forms，WPF，Console，MVC 等技術(shù)棧的應(yīng)用程序中，并且提供了Rest接口可以應(yīng)用在 Javascript，Node.js 中。

它將日志收集變得簡單易用并且不需要了解太多的相關(guān)技術(shù)細節(jié)及配置。

在以前，我們做日志收集大多使用 Log4net，Nlog 等框架，在應(yīng)用程序變得復(fù)雜并且集群的時候，可能傳統(tǒng)的方式已經(jīng)不是很好的適用了，因為收集各個日志并且分析他們將變得麻煩而且浪費時間。

http://exceptionless.com/

https://github.com/exceptionless/Exceptionless

ELK：是三個開源軟件的縮寫，分別為：Elasticsearch 、 Logstash以及Kibana , 它們都是開源軟件。

不過現(xiàn)在還新增了一個 Beats，它是一個輕量級的日志收集處理工具(Agent)，Beats 占用資源少，適合于在各個服務(wù)器上搜集日志后傳輸給 Logstash，官方也推薦此工具。

Apollo（阿波羅）是攜程框架部門研發(fā)的配置管理平臺，能夠集中化管理應(yīng)用不同環(huán)境、不同集群的配置，配置修改后能夠?qū)崟r推送到應(yīng)用端，并且具備規(guī)范的權(quán)限、流程治理等特性。

服務(wù)端基于 Spring Boot 和 Spring Cloud 開發(fā)，打包后可以直接運行，不需要額外安裝 Tomcat 等應(yīng)用容器。

Java 客戶端不依賴任何框架，能夠運行于所有 Java 運行時環(huán)境，同時對 Spring 環(huán)境也有較好的支持。.Net 客戶端不依賴任何框架，能夠運行于所有 .Net 運行時環(huán)境。

https://github.com/ctripcorp/apollo/

⑨分布式鎖

分布式鎖的解決方案有很多，我在這里就羅列一些：

• Consul 可以實現(xiàn)分布式鎖
  

• Redis 可以實現(xiàn)分布式鎖，推薦使用
  

• Zookeeper 可以實現(xiàn)分布式鎖
  

• 數(shù)據(jù)庫可以實現(xiàn)分布式鎖

⑩分布式事務(wù)

分布式事務(wù)的實現(xiàn)方式也不少：

• 2PC（two-phase commit protocol，強一致性，沒有可用性）
  

• 3PC
  

• TCC（Try-Confirm-Cancel）
  

• 本地消息表，推薦 RabbitMQ
  

• Saga 模式

本地消息表：MQ 分布式事務(wù)—本地消息表—基于消息的一致性。

• 上有投遞消息
  

• 下游獲取消息
  

• 上游投遞穩(wěn)定性
  

• 下游接受穩(wěn)定性

?容器化

Docker 是一個開源的應(yīng)用容器引擎，可以打包應(yīng)用以及依賴包到一個可移植的鏡像中，然后發(fā)布到任何流行的 Linux 和Windows 機器上，也可以實現(xiàn)虛擬化。

Docker 使用客戶端-服務(wù)器 (C/S) 架構(gòu)模式，使用遠程 API 來管理和創(chuàng)建 Docker 容器。

Docker 容器通過 Docker 鏡像來創(chuàng)建。容器與鏡像的關(guān)系類似于面向?qū)ο缶幊讨械膶ο笈c類。

Docker 采用 C/S 架構(gòu) Docker daemon 作為服務(wù)端接受來自客戶的請求，并處理這些請求（創(chuàng)建、運行、分發(fā)容器）。

客戶端和服務(wù)端既可以運行在一個機器上，也可通過 Socket 或者 RESTful API 來進行通信。

Docker daemon 一般在宿主主機后臺運行，等待接收來自客戶端的消息。

Docker 客戶端則為用戶提供一系列可執(zhí)行命令，用戶用這些命令實現(xiàn)跟 Docker daemon 交互。

Kubernetes 是 Google 開源的一個容器編排引擎，它支持自動化部署、大規(guī)?？缮炜s、應(yīng)用容器化管理。

在生產(chǎn)環(huán)境中部署一個應(yīng)用程序時，通常要部署該應(yīng)用的多個實例以便對應(yīng)用請求進行負載均衡。

在 Kubernetes 中，我們可以創(chuàng)建多個容器，每個容器里面運行一個應(yīng)用實例，然后通過內(nèi)置的負載均衡策略，實現(xiàn)對這一組應(yīng)用實例的管理、發(fā)現(xiàn)、訪問，而這些細節(jié)都不需要運維人員去進行復(fù)雜的手工配置和處理。

Kubernetes 也可以理解為 Docker 的編排容器，是管理應(yīng)用的全生命周期的工具，從創(chuàng)建應(yīng)用/部署，應(yīng)用提供服務(wù)，擴容縮容，更新，都非常的方便，而且可以做到故障自愈。

http://docs.kubernetes.org.cn/

https://kubernetes.io/docs/home/

Jenkins 是一個開源的、提供友好操作界面的持續(xù)集成（CI）工具，主要用于持續(xù)、自動的構(gòu)建/測試軟件項目、監(jiān)控外部任務(wù)的運行。

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

好了，今天就分享到這里了，沒別的，就是做一下相關(guān)技術(shù)棧的記錄，以后有時間，再把每項技術(shù)仔細研究。