程序人家：你的老板逼你上微服务了吗？？
可均可可
讀完需要
10
分鐘速讀僅需 3?分鐘
這些年軟件的設計規模越來越龐大，業務需求也越來越復雜，針對系統的性能、高吞吐率、高穩定性、高擴展等特性提出了更高的要求。
可以說業務需求是軟件架構能力的第一推動力，由于這些因素導致了軟件架構思想和相關技術也在發生著巨變。
這些變化反應在軟件架構行業里，就是我們開始越來越多的聽到了很多新的詞匯，比如：“分布式”、“SOA”、“微服務”、“中臺”等概念。
今天我就把我學習微服務的過程記錄下來，包括所有技術的實現細節和個人的理解。俗話說：好記性，不如爛筆頭，以防自己忘記，以后可以查詢。
當然，這些東西有很多東西都是自己的理解，里面的插圖也是自己畫的，可能會有一些有失偏頗的地方，當然希望有高手可以指正，不靈賜教，大家共同進步。
1
? ?
架構發展歷程
現在的科學技術可以說是日新月異，發展迅速。相對于我們軟件設計行業也在發生著巨變，業務越來越復雜，需求越來越龐大、繁雜，軟件架構和部署的規模也發生著翻天覆地的變化。
作為軟件架構思想之一的“微服務架構”也在按著自己的規律進化著，接下來我們就簡單的了解一下“微服務架構”發展經歷的三個時期，這些只是個人理解。
1.1
? ?
單體架構（Monolithic）
單體應用時代：應用程序無論如何分層，都是一個解決方案，或者說都是一個項目，這里的“解決方案”和“項目”不是我們使用的 Visual Studio 里面的概念，最終的程序代碼都會在一個進程里運行。
如圖：
優點：開發簡單，集中管理，沒有分布式的損耗，都是系統進程內的通信。
缺點：不好維護，升級困難，耦合嚴重，無法應付高并發和大數據場景，無法快捷迭代。
1.2
? ?
垂直拆分
隨著業務規模的越來越龐大，系統設計就越來越復雜，大的系統就開始進行業務的垂直拆分。
比如：有專門做商品秒殺的部門，有專門做生鮮商品的部門，有專門做超市的部門，等等，當然這是根據部門天生劃分的，也有根據業務需求進行系統劃分的。
如圖：
優點：垂直拆分，系統獨立部署和維護，每個系統在自己進程內執行，分而治之。
缺點：拆分越多，存儲越復雜，系統間重復的東西也越多，單個系統還是單體模式。
1.3
? ?
分布式服務
隨著業務系統的越來越龐大，軟件系統設計起來越來越復雜。為了避免過度復雜的業務需求，開始對業務系統的進行垂直拆分，形成多個獨立的業務系統，如果多個系統之間要通信，可以通過跨進程的技術完成通訊。
但是垂直拆分也導致了大量重復代碼、重復模塊的產生，比如：用戶模塊、日志模塊、支付模塊、認證授權模塊等，這樣分散的代碼也給系統的維護和升級帶來了困難。
我們對業務重新劃分，把獨立的模塊接口化、服務化，提高重用，這個時候，我們就開始進入了分布式服務的時代。（分布式的第一要務就是不要分布式）
如圖：
優點：
獨立進程部署，獨立進程運行，獨立演化。服務之間可以做到高內聚，低耦合。
獨立開發和維護，業務解耦，無論是業務系統還是分布式服務都獨立演化。
分布式管理。
隔離性增強。
由一系列服務組裝成系統，不用重復建設，模塊、代碼可以復用。
缺點：
數據一致性（多服務完成一個任務）和系統的可用性（集群）成為問題。
數據庫也進行了拆分。
維護、設計、架構成本增加，調試、糾錯更難。
網絡傳輸分布式損耗成本。
不適合高并發和大數據的環境。
1.4
? ?
微服務架構
微服務的出現時分布式架構已經很成熟了，架構中各種問題已經有了很成熟的解決方案，對于現在的業務系統來說，分布式架構已經變成了一種常規手段，這個時候，微服務就出現了。
微服務架構是一個用分布式服務拆分業務邏輯，完成解耦的架構模式（架構風格）。
微服務肯定是分布式的一種，是在分布式技術成熟之后，然后把分布式當成解耦手段來架構系統。
因為拆分的服務很細致，服務數量規模開始變多了，服務的體量開始縮小了，由以前幾個大的服務，轉變為多個獨立運行的、原子性質的服務。
如圖：
微服務最重要的特性是：
可用性：描述一個系統在一段時間內提供有用資源的能力，從而減少停工時間，而保持其服務的高度可用性。
伸縮性：根據需求動態添加和刪除系統中資源的能力，是水平或垂直擴展的專門實現。
集群（負載均衡）可以解決系統的高可用和伸縮特性。
1.5
? ?
SOA 面向服務架構
Service-Oriented Architecture 面向服務架構：是一個組件模型，它將應用程序的不同功能單元（稱為服務）進行拆分，并通過這些服務之間定義良好的接口和協議聯系起來。
如圖：
2
? ?
微服務架構的發展歷程
我們要解決微服務的高可用和可伸縮的兩個問題，自然就會想到通過集群來實現，這個思路沒有錯。
如果我們實現了服務集群，那另外兩個問題就會出現，這兩個問題也導致了微服務架構的發展版本的差異。
第一個：服務的發現問題，調用方如何發現服務，有了新的服務，我們如何知道，有服務實例掉線，我們如何曉得，發現服務就很重要，這個是基礎問題，第一個問題不解決，第二個問題也沒有辦法實現。
第二個：如何調用服務，如何管理那么多的服務實例。有那么多的集群實例，也就有那么多的服務實例，我們該怎么去調用這些服務呢？多個服務調用的關系如何呢？
由于這些問題，那我們就看看微服務架構的三個版本是如何解決的。
①集中式代理：Nginx（V1.0?版本（服務注冊/服務發現----手動））
如上圖：
服務發現，手動修改配置文件，重新啟動。
負載均衡，可以輪訓、權重、哈希等等。
服務新增無法發現，需要手動配置，服務掉線可以自動檢查。
客戶端的實現很簡單，不需要額外的代碼，簡單，高效。
②客戶端嵌入：Consul（V2.0 版本（服務注冊/服務發現—自動---服務治理））???
如上圖：
服務注冊與發現，動態增加，自動完成。
健康檢查，可以查看損壞服務，去掉服務，自動完成。
負載均衡，Consul 返回所有活動服務實例，客戶端自己實現負載均衡。
功能強大，自動發現-自動下線，客戶端集成比較復雜，負載均衡在客戶端實現。
③服務網格：Service Mesh（V3.0---技術不成熟，華為+唯品會，lstio）
SideCar 服務管理服務實例的注冊和發現，服務實例的治理和調用。Service Mesh’s Control Plan 管理所有的 SideCar。
這個技術我就不多談了，網上的資料也很多，目前這個技術還不是很成熟，使用的范圍也不是很廣，只有一些大的公司有過使用，比如：微軟等。
3
? ?
微服務架構必備技術棧
微服務是一種軟件設計、架構思想，當然，里面也包含了相關技術點要解決當前要務。學習微服務，我們不能空口而談，一定要落實到具體的技術棧上。
當今使用比較多兩個技術體系，一個是 Java，另外一個就是 Net，廢話不多說，我是使用微軟相關技術棧的軟件架構人員，當然使用的“微服務”架構技術棧也都是微軟的。
今天我就把相關“微服務架構”所用到的技術棧羅列出來，我也要說明一下，微服務架構里面的很多技術是和開發語言無關的，無論是 .Net 還是 Java 平臺都可以使用。以后，一步一步的針對每項技術在做深入研究。
①服務通信
WebService、WCF、WebAPI，甚至可以是 ASHX，ASPX，這都是微軟本身的技術體系，沒什么可說的：
主動觸發
數據序列化傳遞
跨平臺
跨語言
Http 穿透防火墻
②進程通信
Net Remoting：Net 平臺督郵的，不支持跨平臺。
gRPC：高性能、開源和通用 RPC 框架，面向服務端和移動端，基于 HTTP/2 設計，推薦使用。
③API 網關服務（Ocelot）
API 網關：它是系統的暴露在外部的一個訪問入口。這個有點像代理訪問的家伙，就像一個公司的門衛承擔著尋址、限制進入、安全檢查、位置引導、等等功能。
Ocelot 是一個用 .NET Core 實現并且開源的 API 網關，它功能強大，包括了：路由、請求聚合、服務發現、認證、鑒權、限流熔斷。
并內置了負載均衡器與 Service Fabric、Butterfly Tracing 集成。這些功能只都只需要簡單的配置即可完成。
如圖：
官網：
https://ocelot.readthedocs.io/en/latest/index.html④認證&授權
現在的應用開發層出不窮，基于瀏覽器的網頁應用，基于微信的公眾號、小程序，基于 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⑥分布式追蹤
隨著微服務架構的流行，一些微服務架構下的問題也會越來越突出，比如一個請求會涉及多個服務，而服務本身可能也會依賴其他服務，整個請求路徑就構成了一個網狀的調用鏈。
而在整個調用鏈中一旦某個節點發生異常，整個調用鏈的穩定性就會受到影響，所以會深深的感受到 “銀彈” 這個詞是不存在的，每種架構都有其優缺點 。
面對以上情況， 我們就需要一些可以幫助理解系統行為、用于分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題，這時候 APM（應用性能管理）工具就該閃亮登場了。
項目地址：
https://github.com/SkyAPM/SkyAPM-dotnet⑦分布式日志
一般我們需要進行日志分析場景：直接在日志文件中 grep、awk 就可以獲得自己想要的信息。
但在規模較大也就是日志量多而復雜的場景中，此方法效率低下，面臨問題包括日志量太大如何歸檔、文本搜索太慢怎么辦、如何多維度查詢。
需要集中化的日志管理，所有服務器上的日志收集匯總。常見解決思路是建立集中式日志收集系統，將所有節點上的日志統一收集，管理，訪問。
大型系統通常都是一個分布式部署的架構，不同的服務模塊部署在不同的服務器上，問題出現時，大部分情況需要根據問題暴露的關鍵信息，定位到具體的服務器和服務模塊，構建一套集中式日志系統，可以提高定位問題的效率。
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/ExceptionlessELK：是三個開源軟件的縮寫，分別為：Elasticsearch 、 Logstash以及Kibana , 它們都是開源軟件。
不過現在還新增了一個 Beats，它是一個輕量級的日志收集處理工具(Agent)，Beats 占用資源少，適合于在各個服務器上搜集日志后傳輸給 Logstash，官方也推薦此工具。
目前由于原本的 ELK Stack 成員中加入了 Beats 工具所以已改名為 Elastic Stack，推薦使用。
⑧分布式配置中心
Apollo（阿波羅）是攜程框架部門研發的配置管理平臺，能夠集中化管理應用不同環境、不同集群的配置，配置修改后能夠實時推送到應用端，并且具備規范的權限、流程治理等特性。
服務端基于 Spring Boot 和 Spring Cloud 開發，打包后可以直接運行，不需要額外安裝 Tomcat 等應用容器。
Java 客戶端不依賴任何框架，能夠運行于所有 Java 運行時環境，同時對 Spring 環境也有較好的支持。.Net 客戶端不依賴任何框架，能夠運行于所有 .Net 運行時環境。
項目地址：
https://github.com/ctripcorp/apollo/⑨分布式鎖
分布式鎖的解決方案有很多，我在這里就羅列一些：
Consul 可以實現分布式鎖
Redis 可以實現分布式鎖，推薦使用
Zookeeper 可以實現分布式鎖
數據庫可以實現分布式鎖
⑩分布式事務
分布式事務的實現方式也不少：
2PC（two-phase commit protocol，強一致性，沒有可用性）
3PC
TCC（Try-Confirm-Cancel）
本地消息表，推薦 RabbitMQ
Saga 模式
本地消息表：MQ 分布式事務—本地消息表—基于消息的一致性。
上有投遞消息
下游獲取消息
上游投遞穩定性
下游接受穩定性
?容器化
Docker 是一個開源的應用容器引擎，可以打包應用以及依賴包到一個可移植的鏡像中，然后發布到任何流行的 Linux 和Windows 機器上，也可以實現虛擬化。
Docker 使用客戶端-服務器 (C/S) 架構模式，使用遠程 API 來管理和創建 Docker 容器。
Docker 容器通過 Docker 鏡像來創建。容器與鏡像的關系類似于面向對象編程中的對象與類。
Docker 采用 C/S 架構 Docker daemon 作為服務端接受來自客戶的請求，并處理這些請求（創建、運行、分發容器）。
客戶端和服務端既可以運行在一個機器上，也可通過 Socket 或者 RESTful API 來進行通信。
Docker daemon 一般在宿主主機后臺運行，等待接收來自客戶端的消息。
Docker 客戶端則為用戶提供一系列可執行命令，用戶用這些命令實現跟 Docker daemon 交互。
如圖：
?容器編排
Kubernetes 是 Google 開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。
在生產環境中部署一個應用程序時，通常要部署該應用的多個實例以便對應用請求進行負載均衡。
在 Kubernetes 中，我們可以創建多個容器，每個容器里面運行一個應用實例，然后通過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不需要運維人員去進行復雜的手工配置和處理。
Kubernetes 也可以理解為 Docker 的編排容器，是管理應用的全生命周期的工具，從創建應用/部署，應用提供服務，擴容縮容，更新，都非常的方便，而且可以做到故障自愈。
中文社區：
http://docs.kubernetes.org.cn/官網：
https://kubernetes.io/docs/home/?CI/CD
Jenkins 是一個開源的、提供友好操作界面的持續集成（CI）工具，主要用于持續、自動的構建/測試軟件項目、監控外部任務的運行。
官網：
http://www.jenkins.org.cn/4
? ?
結束語
好了，今天就分享到這里了，沒別的，就是做一下相關技術棧的記錄，以后有時間，再把每項技術仔細研究。
原文轉自：https://www.cnblogs.com/PatrickLiu?
- EOF -
想要加入中生代架構群的小伙伴，請添加群合伙人大白的微信
申請備注（姓名+公司+技術方向）才能通過哦！
往期推薦
東方證券首席架構師樊建：企業微服務架構轉型實踐
微博技術專家陳波：百億級訪問量的應用如何做緩存架構設計
天弘基金首席架構師李鑫：微服務接口限流的算法及架構實現
已火 2 年，Service Mesh究竟給微服務帶來了什么？
DevOps是微服務的秘方
導致微服務失敗的 11 個原因
停！你不需要微服務
可能是全網最通俗易懂的微服務架構改造解讀
13 年 Java 老兵的微服務戰地筆記 | 文末有1元福利
Istio微服務平臺集成實踐
胡忠想|微博微服務架構的Service Mesh實踐之路
云原生架構下微服務最佳實踐-如何拆分微服務架構
都在說微服務，那么微服務的反模式和陷阱是什么（一）
當DDD遇上微服務
王東：微服務下的APM全鏈路監控
謝康 | 同程旅游微服務最佳實踐
小程故事多 | 看來微服務就是一把雙刃劍
跟著小程學微服務-Mock自動化系統的原理及實現
微服務大規模化，面臨的挑戰？
十年！我所遇見的微服務演進
? ?END ? ?? #架構師必備#點分享點點贊點在看 新人創作打卡挑戰賽發博客就能抽獎！定制產品紅包拿不停！總結
以上是生活随笔為你收集整理的程序人家：你的老板逼你上微服务了吗？？的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： NYOJ 737 合并石子(一)
- 下一篇： request.getContextPa