大家好，由于當(dāng)前重心在知識(shí)分享視頻的創(chuàng)作上面，因此減少了圖文類文章的更新，但是對(duì)于一些關(guān)鍵點(diǎn)的思考仍然會(huì)更新圖文，重點(diǎn)不在于長(zhǎng)篇大論，而是將我的關(guān)鍵思考點(diǎn)講清楚，內(nèi)容不會(huì)再體現(xiàn)完整的體系化，而是類似經(jīng)驗(yàn)點(diǎn)的分享。
什么意思呢？
就是我的文章你拿去轉(zhuǎn)載沒什么用，內(nèi)容會(huì)很零星，但是這些思考點(diǎn)你沉下心來結(jié)合你自己的工作學(xué)習(xí)實(shí)踐來閱讀，還是會(huì)有幫助。
對(duì)于微服務(wù)，從基本概念到開發(fā)到治理，我在前面都談過相當(dāng)多的文章，今天談這篇文章還是對(duì)于騰訊在北極星后又發(fā)布和開源了一個(gè)云原生標(biāo)準(zhǔn)的一站式微服務(wù)管理框架 Femas。感興趣的大家可以去看下這篇文章。
https://www.infoq.cn/article/KksAEfXidiM2iwZMvZ0q
但是看了以后，發(fā)現(xiàn)這個(gè)平臺(tái)更多還是應(yīng)用到公有云，面對(duì)多租戶的PaaS云原生平臺(tái)中的微服務(wù)管控和治理上面。其本身強(qiáng)調(diào)了多種微服務(wù)開發(fā)框架，類似Dubbo，SpringCloud，gRPC的適配，多種服務(wù)注冊(cè)中心，類似Eureka，Nacos，Consul的納管和適配，多種微服務(wù)和API網(wǎng)關(guān)，多種可觀測(cè)性開源組件的適配。
簡(jiǎn)單來說就是，不論你原來微服務(wù)開發(fā)采用的是什么開發(fā)框架和環(huán)境，微服務(wù)治理采用的是什么開源軟件，都可以納入到Femas進(jìn)行統(tǒng)一的管理。
整個(gè)納入管理的時(shí)候，又不需要對(duì)已有的微服務(wù)框架，微服務(wù)程序進(jìn)行改動(dòng)。
對(duì)于Femas本身也是基于ServiceMesh的思路，通過下放Sidecar邊車代理的方式來實(shí)現(xiàn)各種適配能力，各種安全，日志，限流熔斷，鏈路監(jiān)控能力。
我在前面分享過一篇微軟Dapr微服務(wù)框架的文章，參考：
微軟開源Dapr微服務(wù)框架-云原生應(yīng)用和微服務(wù)發(fā)展主流趨勢(shì)
從Dapr的分層架構(gòu)上，可以簡(jiǎn)單地理解為北向接口和能力開放，內(nèi)部業(yè)務(wù)組件和邏輯實(shí)現(xiàn)，南向底層能力適配三個(gè)方面的內(nèi)容。對(duì)于最上層的API層是最容易理解的，即將內(nèi)部組件能力發(fā)布為API接口服務(wù)，既可以是Http Rest API接口，也可以是Rpc接口，而且可以做到靈活發(fā)布給前端應(yīng)用使用。
對(duì)于Building Blocks，除了架構(gòu)圖里面談到的狀態(tài)管理，資源綁定，發(fā)布訂閱，可觀測(cè)性等能力外，更加重點(diǎn)是是和能力綁定在一起的核心業(yè)務(wù)組件和功能實(shí)現(xiàn)。也就是Building Blocks僅僅是核心組件邏輯實(shí)現(xiàn)附屬的Sidecar能力。核心組件能力如何實(shí)現(xiàn)呢？你仍然可以按照傳統(tǒng)的編程語言來實(shí)現(xiàn)你的核心業(yè)務(wù)規(guī)則和邏輯。
但是這個(gè)開源框架更多是站在公有云PaaS平臺(tái)，面對(duì)多租戶，多種異構(gòu)微服務(wù)應(yīng)用場(chǎng)景的時(shí)候適用。但是回到一個(gè)企業(yè)內(nèi)部的IT應(yīng)用開發(fā)，在微服務(wù)架構(gòu)應(yīng)用和選型的過程中，絕對(duì)不會(huì)說出現(xiàn)采用多種服務(wù)注冊(cè)中心，多種網(wǎng)關(guān)，多種開發(fā)框架的問題。
那么企業(yè)級(jí)微服務(wù)開發(fā)者真正要解決的問題在哪里？
這個(gè)也是我強(qiáng)調(diào)的，對(duì)于企業(yè)內(nèi)的微服務(wù)開發(fā)，應(yīng)該是屏蔽微服務(wù)架構(gòu)，開發(fā)框架，微服務(wù)后續(xù)治理和可觀測(cè)性的諸多復(fù)雜性，真正讓微服務(wù)開發(fā)盡量的簡(jiǎn)單和純粹。
架構(gòu)師應(yīng)該做好這種屏蔽，不是說每個(gè)開發(fā)人員都需要去了解微服務(wù)底層框架技術(shù)原理，都需要去了解復(fù)雜的鏈路監(jiān)控，限流熔斷的實(shí)現(xiàn)。開發(fā)人員更多的重心是在功能的實(shí)現(xiàn)上，而不是微服務(wù)后續(xù)的管控治理。
微服務(wù)開發(fā)和微服務(wù)治理一定要分離。在微服務(wù)設(shè)計(jì)和開發(fā)過程中不應(yīng)該引入任何的微服務(wù)治理內(nèi)容。
先摘錄一段內(nèi)容：
基于傳統(tǒng)組件面臨的種種問題，Red Hat 首席架構(gòu)師 Bilgin Ibryam 對(duì)云原生領(lǐng)域的微服務(wù)架構(gòu)發(fā)展提出了 multi-runtime 的理念。runtime 作為理論的出發(fā)點(diǎn)，Bilgin Ibryam 提出現(xiàn)代分布式應(yīng)用程序的需求分為 4 類，分別是生命周期（lifecycle）、網(wǎng)絡(luò)（networking）、狀態(tài)（state）和綁定（binding）。
- 生命周期：編程語言會(huì)指定生態(tài)系統(tǒng)中的可用庫、打包格式和運(yùn)行時(shí)，自動(dòng)化部署、彈性伸縮、自愈等代表了應(yīng)用程序生命周期的需求。
- 網(wǎng)絡(luò)：從更廣泛的角度去掌握網(wǎng)絡(luò)，例如 DNS、流量管控。
- 狀態(tài)：依賴于底層的狀態(tài)的分布式能力，如緩存、服務(wù)編排和工作流、分布式單例、臨時(shí)調(diào)度。
- 綁定：在跟外部系統(tǒng)的集成過程中，依賴于協(xié)議轉(zhuǎn)化，錯(cuò)誤恢復(fù)等能力。
如上面這個(gè)圖。
簡(jiǎn)單理解就是我只想做好中間方塊內(nèi)容，實(shí)現(xiàn)相關(guān)的功能和API接口的開發(fā)。其它事情都不應(yīng)該讓開發(fā)人員操心。
而其他事情就包括了這個(gè)組件本身的生命周期和運(yùn)行時(shí)管理(容器云集成），東西流量管理（服務(wù)注冊(cè)發(fā)現(xiàn)），南北流量管控（微服務(wù)或API網(wǎng)關(guān)），可觀測(cè)性（狀態(tài)管理，鏈路監(jiān)控），服務(wù)治理（安全，限流熔斷，日志審計(jì)）等。
如果我是開發(fā)者我希望達(dá)到的一個(gè)目標(biāo)就是方塊外圍的各種能力都不需要我在開發(fā)階段去關(guān)心，都是應(yīng)該在后續(xù)可以通過Sidecar邊車代理的模式來靈活配置和實(shí)現(xiàn)。
我開發(fā)一個(gè)微服務(wù)，重點(diǎn)是實(shí)現(xiàn)業(yè)務(wù)功能，并且寫好我的對(duì)外接口函數(shù)。
任何一個(gè)接口函數(shù)本身就應(yīng)該具備多種接口協(xié)議的發(fā)布能力。舉例來說如果是內(nèi)部的各個(gè)微服務(wù)組件之間的調(diào)用，應(yīng)該自動(dòng)化的發(fā)布為TCP+RPC調(diào)用模式以提升接口性能。而對(duì)外發(fā)布才發(fā)布為Http Rest API接口以屏蔽防火墻影響等。
而這些開發(fā)人員也不需要關(guān)心，也需要做到可以靈活配置。
對(duì)于我開發(fā)自測(cè)通過的微服務(wù)，如果通過編譯構(gòu)建，打包，部署和最終交付到容器云平臺(tái)，包括后續(xù)在容器云平臺(tái)如何進(jìn)行資源和狀態(tài)的監(jiān)控，組件資源的靈活動(dòng)態(tài)調(diào)度，開發(fā)人員也不需要關(guān)心，微服務(wù)運(yùn)行的全生命周期管理復(fù)雜性也不應(yīng)該在開發(fā)態(tài)引入。
只有這樣開發(fā)人員真正的重心才能夠放在業(yè)務(wù)功能開發(fā)，業(yè)務(wù)邏輯的實(shí)現(xiàn)上面，而不是去關(guān)注微服務(wù)技術(shù)平臺(tái)。
對(duì)于一個(gè)大企業(yè)也是同樣的道理。
大企業(yè)本身也應(yīng)該是平臺(tái)+應(yīng)用的構(gòu)建模式，可以有獨(dú)立的技術(shù)架構(gòu)和平臺(tái)組來輔助微服務(wù)開發(fā)框架，技術(shù)平臺(tái)，治理平臺(tái)的建設(shè)。而平臺(tái)組提供給上層應(yīng)用開發(fā)組的能力應(yīng)該足夠簡(jiǎn)單，不應(yīng)該將微服務(wù)架構(gòu)本身的一些復(fù)雜性引入到技術(shù)開發(fā)中。
不是每個(gè)開發(fā)人員都需要去詳細(xì)了解微服務(wù)架構(gòu)，開發(fā)框架，各種微服務(wù)治理技術(shù)組件和底層實(shí)現(xiàn)方案，更多的開發(fā)人員應(yīng)該是使用微服務(wù)開發(fā)框架，開發(fā)過程應(yīng)該足夠簡(jiǎn)單，真正將重心放在業(yè)務(wù)和功能實(shí)現(xiàn)上。
這才是一個(gè)微服務(wù)架構(gòu)設(shè)計(jì)的時(shí)候應(yīng)該考慮的關(guān)鍵點(diǎn)。
