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