作者 | 雷卷
來源 | 阿裡技術公衆号
關于微核心架構設計現在比較熱，聽起來好像是作業系統核心相關的，作為Java程式員，作業系統核心那麼遙遠的事情，好像和我們沒有什麼關系。但是如果我說微核心其實就是插件化(Plug-in)架構，你一定會一臉疑惑，“你居然向Java程式員解釋什麼是插件化架構？我每天都在用啊，Eclipse、IntelliJ IDEA、OSGi、Spring Plugin、SPI等，哪個不是插件化架構。我的一些項目也是采用插件化設計的，如使用插件實作流程控制定制等等”。但是别着急，即便是我們每天都在使用的技術，而且大多數人也都知道，如果我們能将其闡述得更清楚，并且能從中發現一些問題，做出一些優化有助于以後的架構設計，那麼大多數人在日常的設計和開發中都能受益，豈不是更好。現在我們就來聊一聊微核心架構設計。
一 微核心設計之作業系統核心
微核心設計其實就是插件體系。我們都知道，作業系統核心誕生得比較早，是以插件化最早被用在核心設計上，于是就有了微核心設計這一稱呼。
微核心是這樣一種核心：它隻完成核心不得不完成的功能，包括時鐘中斷、程序建立與銷毀、程序排程、程序間通信，而其他的諸如檔案系統、記憶體管理、裝置驅動等都被作為系統程序放到了使用者态空間。說白了，微核心是相對于宏核心而言的，像Linux就是典型的宏核心，它除了時鐘中斷、程序建立與銷毀、程序排程、程序間通信外，其他的檔案系統、記憶體管理、輸入輸出、裝置驅動管理都需要核心完成。
也就是說，微核心是相對宏核心而言的，宏核心是一個包含非常多功能的底層程式，也就是我們現在講的Monolith。它幹的事情非常多，而且不是可插拔的，修改一些小的功能，都會涉及到整個程式的重新編譯等，比如一個功能出現了一個小bug，可能導緻整個核心都出問題。這也是很多人将Linux稱為monolithic OS的原因。而微核心隻負責最核心的功能，其他功能都是通過使用者态獨立程序以插件方式加入進來，然後微核心負責程序的管理、排程和程序之間通訊，進而完成整個核心需要的功能。基本一個功能出現問題，但是該功能是以獨立程序方式存在的，不會對其他程序有什麼影響進而導緻核心不可用，最多就是核心某一功能現在不可用而已。
微核心就是一個運作在最進階别的程式片段，它能完成使用者态程式不能完成的一些功能。微核心通過程序間通信來協調各個系統程序間的合作，這就需要系統調用，而系統調用需要切換堆棧以及保護程序現場，比較耗費時間；而宏核心則是通過簡單的函數調用來完成各個子產品之間的合作，是以理論上宏核心效率要比微核心高。這個和微服務的架構設計一樣，我們将Monolith應用劃分為多個小應用後，系統的設計就變得比較複雜了，之前都是應用内部函數調用，現在要涉及網絡通訊、逾時等問題，同時響應時間會被拉長。
聊到這裡，相信大家對微核心和宏核心已經有了一個大緻的了解，看起來各有千秋。但是宏核心有一個最大的問題就是定制和維護陳本。現在的移動裝置和IoT裝置越來越多，如果要把一個龐大複雜的核心适配到某一裝置上，是一件非常複雜的事情，如果很簡單的話，那麼把Linux核心适配到Android核心，甚至到Tesla等車載系統，基本上人人都可以做了。
是以我們更需要一個微核心的架構設計，友善定制，而且非常小，可以實作功能的熱替換或者線上更新等，這就是微核心被提出來的核心需求。但是微核心有一個運作的效率問題，是以在微核心和宏核心之間，又有了Hybrid核心，主要是想擁有微核心的靈活性，同時在關鍵點上有宏核心的性能。微核心設計在理論上确實有效率問題，但是随着晶片設計、硬體性能提升等，這方面或許已經有了非常大的提升，已經不再是最關鍵的問題。
總體下來，核心設計有三個形式，如下：
二 插件化(Plug-in)架構設計
上面聊了微核心在作業系統核心設計中的作用，接下來我們就開始讨論更通用的插件化架構設計，畢竟這個詞大家都明白。
插件化架構非常簡單，就兩個核心元件：系統核心(Core System)和插件化元件(Plug-in component)。Core System負責管理各種插件，當然Core System也會包含一些重要功能，如插件注冊管理、插件生命周期管理、插件之間的通訊、插件動态替換等。整體結構如下：
插件化架構對微服務架構設計幫助非常大，考慮到隔離性，插件可能是以獨立程序方式運作的，那麼這些程序如果擴充到網絡上，分布在衆多的伺服器上，這個就是微服務架構的原型，是以了解微核心的同學都不屑于和你讨論微服務架構，相信你也明白了，除了IT傳統的鄙視鍊因素，原理上确實就是這麼回事。
回到微服務架構設計場景，我們将Plug-in component重新命名為服務(Service)，這個和微核心設計中的服務也差不多，這個時候微服務和微核心就差不多了，都涉及到服務注冊、管理和服務之間的通訊等。那我們看一下微核心是如何解決服務之間的通訊問題的？以下摘自維基百科：
因為所有服務行程都各自在不同位址空間運作，是以在微核心架構下，不能像宏核心一樣直接進行函數調用。在微核心架構下，要建立一個程序間通信機制，通過消息傳遞的機制來讓服務程序間互相交換消息，調用彼此的服務，以及完成同步。采用主從式架構，使得它在分布式系統中有特别的優勢，因為遠端系統與本地程序間，可以采用同一套程序間通信機制。
也就是說，采取的是基于消息的程序間通訊機制。消息最簡單，就兩個接口：send和receive，消息發送出去，然後等着收消息，處理後再發消息就可以了，這裡大家應該也知道了，這個是異步的。回到插件化架構設計中，Plug-in元件設計包含互動規範，也就是和外界互相通訊的接口，如果是基于消息通訊的話，就是send和receive接口，可以說是非常簡單的。
但是這裡還有一個問題，那就是程序間通訊。你可能會問，這個有什麼好疑問的，就是兩個程序之間互相發消息呗。但是這裡有一個最大的疑問，那就是程序間通訊是否有第三者介入？如下圖：
當然在作業系統的核心設計中，一定是通過核心進行轉發的，就是我們了解的總線架構，核心負責協調各個程序間的通訊。這個大家也能了解，如果程序A直接發給另外一個程序B，必然要了解對應的記憶體位址，微核心中的服務是可以被随時替換的，如果服務不可用或者被替換，這個時候要通知和其通訊的其他程序，是不是太複雜？剛才已經提到，隻有send和receive接口，沒有其他通知下線、服務不可用的接口。在微核心的設計中，一定是通過總線結構，程序向Kernel發送消息，然後kernel再發送給對應的程序，這樣的一個總線設計。實際上很多應用内部在做Plug-in元件解耦時，都會使用EventBus的結構，其實就是總線的設計機制。
為何婆婆媽媽說這些？因為非常關鍵。分布式的程序通訊是微服務的核心，我們了解的服務到服務的通訊，就是服務A啟動監聽端口，服務B會和服務A建立連接配接，然後兩者通訊即可。這個方式和微核心設計中核心負責消息接收和轉發的總線架構設計是不一樣的。如采用HTTP，HSF等通訊協定時，相當于kernel告知通訊的雙方各自的位址，然後它們之間就可以通訊了。然後就沒有Kernel什麼事情了，也不會用到什麼總線的結構設計，這個就是傳統的服務發現機制。
但是還有一種模式，就是完全透明的插件化通訊機制，如下圖：
Plug-in元件，也就是微服務架構中的服務，是不能直接通訊的，而是需要Core System進行轉發。這樣做的好處和微核心架構一樣，插件互相之間無直接聯系，彼此之間非常透明，例如服務A下線後，完全不需要通知其他服務；服務A被替換，也不需要通知其他服務；服務A從資料中心1到資料中心2，也不用通知其他服務；即便服務N和服務A之間網絡不互通，兩者之間也能通訊。
這裡有個問題：性能問題。我們都知道，兩點之間，直線段最短。為何要多繞一下到Core System呢？這就是微核心和宏核心之間的争論之處，使用函數調用非常快，而程序間的消息通訊則是非常慢的，但是這種通過中介進行通訊機制的好處也是非常明顯的。那麼如何提升這種基于總線的通訊性能呢？當然有，比如選擇高性能的二進制協定，HTTP 1.1這種文本協定就不需要了；采用Zero Copy機制，可以快速進行網絡包轉發；好的網絡硬體，如RDMA；好的協定，如基于UDP的QUIC等。總結下來，和微核心一樣，這種微服務通訊的性能是可以提升的。當然如果實在受不了這種性能，在關鍵場景，你可以采用Hybrid模式，混入一些服務之間直接通訊的設計，但隻能在性能極緻的場景中使用。
此外，插件化架構中的插件元件是各種各樣的，通訊的機制也各不一樣，一些是RPC的，一些是Pub/Sub的，一些是無需ACK的（如Beacon接口），還有一些是雙向通訊的等等。當然你可以選擇不同的通訊協定，但是這裡有一個問題，就是Core System需要了解這個協定，然後才能進行消息路由。這個時候Core System需要編寫大量的Adapter來解析這些協定，例如Envoy包含各種filter來支援不同的協定，如HTTP、MySQL、ZooKeeper等，但是是以Core System就會變得非常複雜且不穩定。
另外可以選一種通用的協定，Core System隻支援這一種協定，各個插件之間都基于該協定通訊，至于服務和其他外部系統如何通訊，如資料庫、github內建等，這些Core System并不關心，那隻是Service内部的事情。目前比較通用的協定是gRPC，如K8s内部都會采用該協定，另外Dapr也采用gRPC協定做服務內建，因為gRPC提供的通訊模型基本可以滿足大多數的通訊場景。當然另外一個就是RSocket，提供更豐富的通訊模型，也适用于Core System這種服務間通訊場景。對比gRPC，RSocket可以運作在各種傳輸層上，如TCP、UDP、WebSocket、RDMA等，相反的，gRPC目前隻能運作在HTTP 2之上。
三 服務通訊的延伸
前面說到，最好由插件化架構設計的Core System作為服務之間消息通訊的路由，如果是這樣的話，就會産生一種Broker模式，當然也有可能是Agent。這裡大家一定會想到Service Mesh，沒錯。當然你可以選擇Agent Sidecar模式，也可以選擇中心化的Broker模式，這兩者的功能都是一樣的，隻是處理的方式不一樣而已。Agent基于服務注冊和發現機制，然後找到對方服務的Agent，再進行兩個Agent之間的通訊，隻是省掉服務之間的調用的開銷。但是Broker是集中式的，大家都向Broker發送和接收消息，不涉及服務注冊發現機制，不涉及服務元資訊推送，就是總線結構。
我現在做的就是基于這種Broker的總線的架構設計，在RSocket Broker中，也是采用微核心架構設計，當然未必做得最好 。RSocket Broker核心就是管理注冊的服務、路由管理、資料采集等，而不會添加過多的功能，和Core System的設計理念一樣，隻添加必須的功能。如果你要擴充整個系統更多的功能，如發短信、發郵件、對接雲存儲服務等，需要編寫一個Service ，然後和Broker對接一下，再從broker那裡收消息（receive），處理完畢後再發送（send）給Broker就可以了。總體結構如下：
有不少同學會問，當服務執行個體的負載太高的時候，Broker如何實作動态擴容呢？Broker會給你提供資料，如一個服務執行個體QPS，至于是否擴充，你隻需要寫一個服務，從Broker上采集資料，分析後，調用K8s API進行擴容即可，Broker并不負載這些業務功能，它隻會添加非常必要的功能，這個和Core System設計是一樣的。
回到插件化架構的靈活性上，如果系統中有一個KV存儲的插件，你隻要遵循消息格式或者通訊接口，就可以儲存KV資料。但是你并不太關心是Redis存儲的，還是Tair存儲的，或者是雲端的KV服務，這就為服務标準化和可替換性提供了很好的基礎，這對應用上雲或雲原生化幫助非常大，整個系統有非常大的靈活性。
四 總結
其實有非常多的書有關于微核心的介紹，作業系統的圖書就不用說了，另外兩本書也非常不錯，對通用架構設計幫助也非常大，尤其是微服務的場景，我也是參考這兩本書寫這篇文章的。
微核心架構設計對微服務設計有非常好的參考意義，但是微服務有一個非常大的問題就是服務邊界的劃分，對比作業系統，已經發展幾十年，而且非常穩定，功能劃分非常容易。而微服務架構是為業務服務的，雖然面對的業務可能已經存在上百年，但是軟體化、數字化和流程化并沒有多少年，加上現實業務的複雜性，還有各種妥協，個人認為微服務架構會更複雜一些。