什麼是微內核架構
相信你們都據說過微內核架構，也或多或少作過一些相似於微內核架構的設計，爲了能夠更好的設計出微內核的架構，咱們瞭解下什麼是微內核架構。redis
說到微內核架構，你們首先會想到的是Eclips、IDEA、OSGI、Spring Plugin、SPI等，這些都是咱們熟知的微內核架構。有了微內核架構，咱們能夠更好的定製和控制流程，因此微內核架構的設計思想常常在作配置化中臺項目的方案中出現的。api
微內核架構實現主要是插件化思想（Plug-in），是一套插件體系，最先的插件化方法是應用在操做系統之上，長此以往就有了微內核設計這一思想。性能優化
瞭解微內核，須要先了解這個「內核」。網絡
在操做系統中，內核圍繞於操做系統的核心功能，好比時鐘中斷、進程建立與銷燬、進程調度、進程間通訊等內核態的動做。而文件系統、內存管理、設備驅動等都被視爲非內核能力，這部分會被放在用戶態空間。架構
微內核是相對於宏內核而言，宏內核包含了不少的底層程序功能，作的事情很是多，並且不是可拔插的，修改任意一個功能點，都須要整個程序聯動，並且有可能引入一個bug，致使整個內核不可用，相似於一個功能複雜的單體系統，每次變動和交付成本都很是高，風險也很是大。分佈式
而微內核只圍繞於核心功能設計，他的功能實現都是相互獨立的，其餘非核心功能是經過用戶態的獨立進程以插件的方式加入進來的，微內核引擎複雜管理進程、調度進程、進程之間通訊。某一個功能出現問題時，因爲其是獨立的進程，不會對其餘進程產生影響，也不會致使內核不可用。函數
微內核中，多個進程協調通訊，須要進行系統調用，系統調用須要切換堆棧及保護進程現場，過程比較耗時。 宏內核（也就是用戶態）中，是經過函數調用完成各個模塊之間合做，因此宏內核較微內核效率更高。微服務
經過操做系統微內核概念，能夠類比到業務系統。一個系統，特別是通過微服務拆分以後的系統，都會服務於某個「內核」，多個核心功能經過微服務的方式拆分，服務之間經過通訊交換數據。經過微內核解決了快速交付問題，實現了代碼隔離，控制風險點的目的。性能
而考慮到擴展性，咱們須要定義出內核的骨架，並開放出plugin，以實現個性化擴展。這樣的微內核架構，咱們能夠便於定製，改動小，進而實現熱更新，這也是微內核架構的主要價值。優化
微內核架構設計
在微內核架構中有兩個核心組件：系統內核、插件化組件。
系統內核：主要解決的是內核的核心功能，好比插件的註冊與管理、插件生命週期管理、插件之間通訊、插件的熱加載與替換。
結構以下：
基於微內核的插件化設計，咱們能夠實現組件隔離，每一個插件能夠以獨立jar包或獨立進程運行，這些插件組件進程能夠獨立部署在分佈式網絡上，實現水平擴展，某種程度就像咱們的微服務治理體系，有獨立部署的微服務進程，也有中心治理的註冊中心與配置中心。
在操做系統中，微內核與宏內核通訊方式上有以下區別：
微內核架構下，組件之間的通訊也是基於消息的，好比每一個組件對於消息處理有兩個能力：收（receive）、發（send）。
那兩個進程之間通訊，是否須要一個三方中介呢？好比這樣：
在操做系統中，消息的通訊是基於內核轉發的，也就是咱們常常據說的消息總線架構，內核複雜協調各個進程的通訊，好比進程A想要發送消息給進程B，須要知道B對應的內存地址。進程向內核發送消息，內核再將消息發送給對應的接收進程，這樣是一個總線通訊過程。
在不少微內核架構設計實現上，組件之間均可以經過EventBus實現Plug-in之間的解耦，也就是借鑑了總線的設計。
在微服務架構的通訊實現上，在SOA時代，有相似於消息總線的概念。但大部分是進程之間的直接調用，沒有了這個所謂的總線。
可是若是引入了一箇中心化的服務註冊與發現中心，他可能也會有個所謂的內核中轉：
在插件化系統中，組件之間不直接通訊，而是藉助於一箇中心化的內核系統進行轉發。這種設計思想很是相似於操做系統的內核轉發實現，插件之間隔離、透明。某個組件下線或替換，其餘組件不須要感知。
這樣的架構會存在於一些其餘的問題。首先，這個中心化的轉發中介變成了單點，其可用性嚴重影響了整個系統的可用性。當中心化系統變成單點轉發，就存在對應的性能問題。
對於遠程進程調用的性能優化，咱們能夠想到這幾點：
- 採用高性能的二進制協議代替http1.x協議，由於http1.1的文本協議性能較差；
- 採用相似於零拷貝機制，實現快速網絡包轉發，而不須要作內核態與用戶態的轉換；
- 引入好的網絡硬件，好比RDMA；好的協議，如UDP、QUIC等；
- 選擇不一樣的通訊方式，好比RPC的、Pub/Sub的、無序ACK的、單工/雙工通訊的等；
爲了處理這麼多協議的轉發，內核系統須要具有Adapter以實現對於衆多協議的解析與轉發，好比引入多個filter來支持不一樣的協議，可是他將變得愈來愈複雜。
還有一種思路是，內核服務只支持一種協議，各個插件之間也基於這個協議通訊，協議的適配與轉換是各個組件本身作就能夠。
其實不少人會想到，這個中心化的內核組件的消息轉發不就是相似於一個MQ系統的Broker嗎？而那種獨立處理通訊協議的組件不就相似於Mesh設計嗎？
沒錯，前一種相似於相似於broker，後一種相似於service mesh或agent思想。功能上是同樣的，只是處理邏輯上有些差別。
broker是集中式的，全部組件經過broker進行消息的收發，設計到註冊與發現機制。 mesh是基於服務的註冊與發現，消息發送須要找到對方的agent，再實現兩個agent之間的通訊。
broker方案設計核心在於，broker須要管理註冊的服務、路由的管理、數據的採集等這些核心功能，相似於微內核的內核自己理念同樣。若是要擴展整個微內核架構能力，須要編寫獨立的service，以後和broker對接，在broker接收消息，處理完畢後發送消息。
那中心的broker負載過高如何擴容呢？由於broker自己具備服務調用的數據採集能力，因此能夠從這裏採集，做爲擴縮容的參考，通過分析後，能夠調用k8s的api實現pod的擴縮容了。
咱們能夠發現，這套圍繞於內核的核心設計以及擴展service的思想很是的雲原生，好比上層業務系統想要調用存儲服務，微內核系統能夠對外提供一個消息存儲的api，而這套api能夠按需擴展是基於redis、仍是tair或是其餘kv，爲服務標準化和可替代性提供了很好的基礎，對上雲操做很是友好，也就體現了雲原生的靈活性。
中心化轉發和點對點發送，兩個方案各有優缺點，架構就是一個取捨的過程，咱們須要結合本身系統的特色和體量決定選擇合適的方案。
總結
微內核架構對於咱們作微服務設計，或是偏中臺、平臺系統設計提供了很是好的參考建議，好比對於微服務邊界的劃分，咱們徹底能夠參考操做系統的設計，通過幾十年的發展，其設計之精妙已經被驗證了，很是穩定，功能劃分也很是合理。