前言
上一篇對微服的演變、優缺點進行了概述，對於業務復雜項目，微服務算是比較合適的解決方案；對於咱們開發者來說，有好的解決方案肯定要跟進學習，但不能盲目追崇流行技術，目的還是為了解決問題。這里就把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系列分享完之后，還會穿插數據庫優化系列的文章。
一個被程序搞丑的帥小伙，關注"Code綜藝圈"，跟我一起學~
