前言

上一篇對微服的演變、優缺點進行了概述，對于業務復雜項目，微服務算是比較合適的解決方案；對于咱們開發者來說，有好的解決方案肯定要跟進學習，但不能盲目追崇流行技術，目的還是為了解決問題。這里就把Asp.NetCore落地微服務架構技術棧匯總一下(當然不限于此)，同時制定了個學習分享計劃，和小伙們一起共勉；

正文

將涉及的技術棧將其分為如下幾個階段進行歸類，后續學習分享的大方向也是如此：

對于需求階段業務分析、測試階段相關及最后應用階段的服務，這系列暫時就先不涉及，而是主要針對開發技術、代碼管理、應用部署、運維管理方面的技術進行匯總和學習分享；對于上圖的各個階段，可能在很多大公司將其職責劃分得很清晰，但對接避免不了(DevOps)，所以了解和學習是很有必要的；如果是中小型公司，那可能開發是你、部署是你、運維還是你，技多不壓身，來了就干，不服就來學。

注：不是在項目中使用以下提到的技術就是微服務，而微服務指的是業務之微，技術只是對其進行落地實現；

開發階段

對于實現，在開發階段涉及的組件或框架頗多，所以得花更多時間進行學習和實戰，如下：

?開發階段

認證中心

當劃分的服務增多時，單個服務的認證和授權顯得更加冗余，更希望有一個統一的認證站點，每一個服務的認證都由認證中心站點進行處理；咱們可以從零自己實現OAuth 2.0和OIDC提供授權和認證功能，輪子肯定有人造好了，拿來就用多好，IdentityServer 4將授權和認證都有很好的實現，從而使得開發人員有更多的時間關注在業務開發上。

服務發現

當服務不多的時候，可能手動進行API地址配置，實現調用還可以接受配置復雜性，如果是對服務進行增加服務器擴展時，還得手動進行配置，那干這活的肯定要噴臟話了。如果使用Consul做服務發現，自動識別各個服務，同時還能進行健康檢查，及時過濾掉不可用服務，增強高可用，顯得更加智能化；減少人工配置的復雜性，還能提升服務的高可用。

網關(Gateway)

網關的主要作用是進行路由轉換、統一入口、隔離內網等，當然還可以做一些服務熔斷、限流、重試、緩存等相關功能。功能具體是什么意思，怎么實現？在后續的學習分享時會一一說到。而.NetCore中常用的網關為Ocelot和Kong；

• 路由轉換：根據配置規則，將不同業務地址轉換到對應的微服務地址上，讓業務請求由對應的業務API進行處理；

• 統一入口：對于UI界面而言，只關心一個入口，即網關地址，不用和每個微服務直接打交道，降低請求訪問復雜性；

• 隔離內網：對外提供地址為網關地址，內部服務通信都是通過內網，使得站點安全性增強；

• 其他功能會在后續實操中一一說到；

服務間通訊

雖然拆分成了各個小服務，但始終還是一個系統，對于一些業務依賴關系的服務會進行聚合或是通過服務間通信，將數據整合統一返回給UI層；常用的技術手段是通過Restful Api接口或是gRPC進行數據交互，然后再進行數據業務處理。

服務治理

每一個小服務也是一個程序，就有可能出現Bug、網絡通信異常、服務器宕機等情況而導致服務不可用，通常我們理想狀態肯定是希望其他服務不被異常服務影響，這樣就需要對服務進行治理，比如失敗重試、服務熔斷、失敗降級等，從而提升服務的可用性，避免單個異常服務導致整個系統雪崩的現象；.NetCore中會使用Polly庫實現相關功能。

NoSql-非關系型數據庫

通常的高并發場景下需要進行緩存和數據共享，實現高可用，而目前Redis是一個很不錯的選擇。對于一些文檔型數據，MongoDB存儲更有優勢，當有大量數據時，會有一些列存儲的數據庫；對于搜索實現，ElasticSearch存儲實現會更加符合場景；

消息隊列

消息隊列的三大好處：異步處理、解耦、削峰；通常在微服務系統業務處理中，遇到一些復雜業務，需要耗費較長的時間，這樣給用戶體驗就不友好，咱們可以將涉及的業務通過消息隊列分發給不同服務處理，然后及時響應給用戶，業務后臺異步處理，體驗感覺就不一樣；可能有小伙伴還會說，直接多線程不就得了，如果是這樣的話，那業務可能都耦合在一塊，后期維護又是一個很大問題；對于一些高并發系統，估計平時服務器都能承載請求，但是存在某一時間段高峰訪問，如果請求都打到后臺服務數據庫，數據庫可能抗不住，像這種短時段高峰的情況，可以通過消息隊列進行削峰，避免高峰時刻搞崩系統；目前比較常用的消息隊列有：Kafka、RocketMQ、RabbitMQ。

CAP

微服務就是分布式，既然是分布式，那分布式事務就避免不了，最終數據一致性的問題那得解決；對于分布式來說，這是老生常談的問題了，并且提供了相關的解決方案，而在.Net中，有大神就封裝了CAP，并將其開源，配合消息隊列很好的實現了分布式事務控制；

Apollo

試想，如果每個服務都有一套自己的配置文件，那部署和運維是不是很頭痛，而且對于一些公共配置數據也會重復在每個服務中配置使用，如果有一套統一的配置中心是不是感覺非常爽，所有服務的配置數據通過一個點進行維護和使用，不管在開發維護、部署還是運維方面，都帶來便捷性；可以自己實現，也可以使用第三方的，而Apollo現在相對來說是比較火的，也有一些直接使用Consul扮演配置中心的角色；當然還有使用在K8S自帶的配置中心。

后臺任務

既然用到微服務項目，應該數據量也不會小，通常會做一些報表分析，數據同步等操作，而這種耗時操作不希望在業務高峰時期執行，需要在空閑時間定時操作即可，針對這種場景后臺定時任務就有用武之地啦。當然不僅僅是這種場景，還有一些做業務數據重放或修復，比如一個訂單在操作中異步處理失敗了，可以在后臺任務檢查過程中，進行再次處理等；在.Net中用的相對比較多的是Quartz.Net和Hangfire。

代碼管理

代碼應該不用多說了，小伙伴們應該都摸清門路了，簡單畫個圖，如下：

代碼管理

代碼規范

不管什么架構，代碼規范一直是開發者嚴格要求的，開發過程中得有良好的編碼規范，雖然每一個公司的要求不太一樣，但最終的目的是一致的：規范化，這樣在后期維護就不會花費大量的時間去研究之前代碼為什么要這么寫。為了規范，周期性的Code Review是必不可少的。

代碼版本管理

對于代碼版本管理工具，用的最多應該是git和svn了，其中對于分支的管理是非常重要的，比如臨時修復線上Bug怎么辦，常規開發怎么辦，緊急功能開發又怎么劃分處理，合理的規劃代碼分支不會讓代碼版本混亂，從而引起功能的不完整或異常；別小看這一件事，經常因為版本分支問題導致生產功能出問題的事件比比皆是，所以小伙伴開發過沖要注重哦，因為持續集成離不開代碼的管理；

部署

提到部署，可能有的小伙伴會說，這不是運維搞的嗎，或者說這不應該有專門的人搞嗎？是的，理想是這樣的，但事實就是，小伙伴不僅負責開發，還得要部署，對于職責分明的團隊，至少你也得會，不然對接有一大堆的尷尬。

部署階段

操作系統

現在部署更多的是推薦在Linux上了，像Redis、ES、nginx等都是在Linux中發揮更好的性能，而對于Linux估計有些小伙伴還不熟，甚至只是聽說，還沒操作，不說多的，關于開發和部署相關日常操作到時候我們來一起聊聊，高深操作可以抽時間再去研究。當然，Windows的操作到時候也能提到，畢竟現在Windows服務器也沒有說不用。

持續集成(CI/CD)

老式的手動發布和部署在微服務中顯得力不從心了，那么多服務，做重復操作，換做任何一個人也受不了，如果多發幾次迭代，那這人就別干其他活，就負責發布妥了。想想，如果這些事自動化解決豈不完美，而Jenkins搭配代碼管理軟件就能很好的實現，自動拉取代碼->自動構建->自動部署，代碼管理軟件可以自己搭建，比如Gogs，或者使用gitlab、github等都行。通過監聽代碼的提交，就能自動完成，想想都美。

容器化

開發和運維干架啦，一個說在我這行，一個說在我那不行， 別說那么多，先干架再說；哈哈哈，為了不允許這種事發生，容器化顯得很屌，開發發布打包生成鏡像，運維拉下來就直接跑，啥都一樣，還有的說嗎；其實主要的目的還是提升工作效率啊，現如今Docker是火的旺旺的，但K8S的棄用能否讓它走下坡路，這似乎好像不太好說；

容器編排

當容器集群擴展增多時，就得有一個東西進行管理，否則擴展會顯得超級麻煩，而K8S就很吃香，針對容器集群管理更好的自動伸縮、自動部署，還能搭配探針實現自修復；

運維

功能開發完了、代碼也上傳了、站點也部署了，用戶開始用吧，后續就很輕松了；no，no，no，這才開始，應該很少有小伙伴拍著胸脯說，沒事，我做的功能都沒問題，絕對沒Bug，好，先假設開發沒問題，斷電、宕機、斷網咋整，這種物理問題不能避免吧，不管是做異地多活也好，還是有其他方案，至少得去弄吧；那如果是業務問題呢，排查問題更多的是靠日志了，對于微服務這種架構，有一個調用鏈的追蹤會提供很好的輔助，來，先看看需要什么技術工具：

運維階段

日志分析

之前單體架構，登上服務器，拷貝日志下來分析妥了，而對于微服務，這似乎不太可取，拷貝日志不僅麻煩還耗時。如果使用Exceptionless將日志統一收集在一起，是不是稍微好那么一點，再加上做一個ElasticSearch和Kibana的查詢分析，是不是又加快了問題的分析速度。

鏈路追蹤

微服務間的數據交互肯定避免不了，有一個可視化的調用鏈路及監控就顯得更加直觀，清楚的看到每次接口調用經過的服務點，對于定位問題來說也提供很大的幫助，能快速知道這次異常經過哪些服務處理，縮小范圍。而用的相對比較多的是SkyWalking和Butterfly。

分布式監控系統

微服務情況下，只要一發布，就不知道什么情況，這樣只有在問題發生之后，才能去排查；有沒有一個監控系統，對系統和服務運行環境進行監控，能在危險范圍內的時候提前給個告警，及時通知相關人員處理呢，prometheus搭配Grafana能將監控數據友好的展示和配置，從而實現對服務運行環境的監控。

總結

對于微服務，還是開篇說到的，不是使用以上技術就是微服務架構，而服務的劃分更多是通過業務進行劃分，技術只是幫助其落地；

以上針對于各階段的技術棧匯總并不涵蓋全部，僅僅是當下相對比較火，且周圍朋友用的比較多的，有什么好的技術，小伙伴可以分享。

這個戰線拉的很長，但肯定會堅持學習分享。期間把Redis系列分享完之后，還會穿插數據庫優化系列的文章。

總結

以上是生活随笔為你收集整理的微服务技术栈及分享计划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。