微服務技術棧及分享計劃

前言

上一篇對微服的演變、優缺點進行了概述，對於業務複雜項目，微服務算是比較合適的解決方案；對於我們開發者來講，有好的解決方案確定要跟進學習，但不能盲目追崇流行技術，目的仍是爲了解決問題。這裏就把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綜藝圈"，跟我一塊兒學~