xPort V1.0 - 基於"Service Mesh"下一代分佈式微服務框架
繼發佈面向量化金融的C++分佈式xRPC通訊框架後，數字動能再發佈用於分佈式服務框架的智能代理xPort v1.0。xPort智能代理完全由C++編寫，支持數字動能的xRPC通訊協議，主要用於實現多應用服務在分佈式服務框架（如Service Mesh服務網格）的智能調度和管理功能。xPort v1.0智能代理的發佈，標誌著數字動能將掌握下一代分佈式微服務架構-Service Mesh的核心開發技術。利用最新的分佈式微服務架構，數字動能可具備搭建多元異構業務中臺、實現複雜業務解耦和跨業務間通訊、滿足多業務場景交付的能力。
一、xPort是什麼？
智能代理，也叫Side Car，既是新一代分佈式微服務框架-Service Mesh服務網格架構的基石構件，也是Service Mesh數據平面和控制平面的核心管理組件。
ISTO的Service Mesh通用模型
xPort是數字動能的Service Mesh核心組件"智能代理"（也叫Side Car）。xPort以分佈式通訊框架xRPC為主要通訊協議，它主要負責Service Mesh服務網格節點間的數據平臺與控制平面的管理。服務網格-Service Mesh被視為下一代基於分佈式思路的微服務架構，它提出了利用全新的分佈式、輕量級設計的Sidecar（以下稱智能代理）部署模式替代原來龐大的層級式、堆疊式的集中服務框架。應用服務間的數據通訊將由智能代理接管，不再需要關注通信和控制細節，信息可在服務網格間高速通訊。而對於系統級別的功能調用，應用服務單元也無需再去關心如何調度，完全由智能代理負責數據平臺和控制平面的協調。這種改進將把業務代碼和技術實現進一步解耦，技術架構的變動對業務代碼的影響也進一步減少。利用智能代理進行應用服務間信息通訊的方式是Service mesh服務網格設計的核心思路，數字動能提出的Direct Exchange Mesh服務網格架構對比ISTO經典Service Mesh模型更輕量級，主要針對金融行業的大數據傳輸、複雜計算和高速傳輸需求進行了場景針對設計。其智能代理xPort完全自主研發，採用大量創新設計。
數字動能的Service Mesh 改進模型
二、智能代理xPort v1.0有什麼特點？
1、智能代理通訊不再經過通用模型的控制面板而是直接數據交換模式
Service Mesh通用模型中，智能節點（Side Car）區分了數據平面和控制平面。但在面向應用服務，以松耦合和高速通訊為首要目標的Direct Exchange Mesh服務網格設計中，數字動能利用xPort智能代理大膽把控制平面的部分功能下沉至智能代理內部，同時把硬件資源的調度權交回給IaaS層，讓整個分佈式架構設計更輕量級，以智能節點直接點對點方式進行數據交換（Direct Exchange Model）。在原Service Mesh通用模型中，應用服務的微服務化看似松耦合，實際上由於控制面板的集中通訊設計，反而加重了網絡間節點傳輸的壓力。數字動能的xPort智能代理大膽取捨了原來控制面板的功能，改為智能代理間完全點對點直接通訊，從而避免過多的節點需要同時經過控制平面通訊所產生的原生架構性能瓶頸。
2、智能代理xPort允許應用（服務）通過進程內調用的方式實現高速點對點通訊
普通Service Mesh的SideCar只是做了消息轉發，xPort在滿足該功能的前提下，可以更好的滿足金融業務（如投研業務）間大量數據和傳輸。智能代理xPort直接把應用服務加載到自身的進程內， 這樣應用服務和智能代理xPort的通訊無需再通過網絡避免了頻繁通訊產生的網絡高負載，而是直接通過內存交互。如下圖，應用服務A和應用服務B都是加載在xPortA的，通訊流程為：應用服務A -> xPortA -> 應用服務B。即使兩個應用服務加載在不同的xPort，也只需要發起一次網絡調用即可。另外，不同於原來一對一的智能代理->應用服務的單一結構，xPort允許多個應用服務同時在進程內加載。如圖，應用服務A，B，C可同時通過加載在xPortA中。
利用xPort實現進程內多應用服務調用
3、智能代理xPort內置服務發現功能，降低對註冊發現服務頻繁訪問的網絡消耗
通用Service Mesh服務網格模型對服務註冊中心的依賴度很高，應用服務通過智能代理必須和服務註冊中心保持連接，以確保服務註冊中心能觀測到各個節點的狀態變化。這種方式在大規模的分佈式應用中容易產生單點問題，隨著應用服務節點的數量增加，服務註冊中心的壓力會隨之變大，一旦服務註冊中心發生故障，所有的應用服務都將被掛起無法工作。xPort為避免此問題，在智能代理中內置了服務發現功能。當應用服務把消息傳遞給xPort後，智能代理會先查詢內置的本地路由表，查看是否有目標應用服務的地址，如果沒有才會從服務註冊中心獲取目標服務（應用）的地址。對於首次應用服務註冊，只需要通過智能代理向服務註冊中心做一次性註冊，後面的所有調用或應用服務目標的狀態無需再通過服務註冊中心。如上圖的服務（應用）A發送消息給應用服務D，當xPortA和xPortB通過服務註冊中心建立連接後， xPortA和xPortB會開始自動相互各自的應用服務信息，不再需要通過服務註冊中心。
4、xPort具有帶消息隊列的點對點通訊功能
在通用Service Mesh架構中，應用服務和智能代理、智能代理自身相互之間均是點對點通訊。點對點通訊在獲得高性能的同時，卻要求被調用方必須保持在線。在分佈式場景中，應用服務可能會出現短時間（或極短時間）的通訊中斷現象。xPort智能代理將會允許這些臨時中斷現象的發生，並將其視為信息在節點間傳輸的有效生命週期。xPort通過改進並融入ZeroMQ的技術達到此目的。應用服務把消息傳給xPort之後，會在本地創建該消息目標應用服務的隊列，然後再由該應用服務把消息發送給目標應用服務；如果目標應用服務不在線，那麼在消息的生命週期內會存放在這個隊列裡面，待目標應用服務上線，該隊列會繼續完成消息傳輸。因此，智能代理間的消息傳輸只要在其生命週期內被處理即可，並不要求各個智能代理節點必須立即響應。與原來傳統點對點的即時信息通訊方式不一樣，xPort在與應用服務和智能代理間的相互調用，並不認為只要對方不在線，消息傳輸就是失敗的，而是允許消息只要還在生命週期內，都可以隊列方式進入等待響應狀態。在點對點通訊效率提升方面，xPort同時借鑑了RabbitMQ一個連接可以創建多個通道（channel）的思路，大大減少了xPort之間的連接數量。xPort內置的節點智能連接算法，可讓xPort智能代理會根據服務節點間線路情況自動增加連接，在空閒時自動降低連接數量。
5、xPort同時支持多線程編程模型和Actor編程模型
通用Service Mesh的架構中，智能代理（Side Car）只作為消息代理所用，xPort在實現消息代理功能的同時，允許應用服務加載到自身進程，使其具備對應用服務的調度功能。為滿足高併發的使用場景，xPort進一步提供了線程池和Actor兩種併發模型。線程池併發模型的多個線程間交互是通過共享內存的方式進行的，多個線程對共享進行操作，達到同步消息的目的。這種方式極大提升響應速度，降低延時，但多線程編程模型難以保證應用運行的正確性。該問題需要用到鎖等機制來解決，這將會影響性能，並且容易導致死鎖等問題。因此，xPort同時提供了Actor併發模型。Actor不是通過共享內存來通信，而是通過通信來共享內存的。Actor的狀態由自身來進行維護，其他線程不能直接對Actor發起調用，而是要把調用的消息發送給Actor，由Actor來執行操作，這樣就可以保證Actor內部的數據只有由它自身進行改變。這種編程模型大大的降低多線程編程的複雜度，容易編寫出高併發的應用程序。xPort的使用對象可以根據業務選擇不同的編程模型即可。
三、xPort可以解決什麼問題？
xPort作為數字動能分佈式微服務框架DX Mesh的核心組件，主要解決各個應用服務間的數據、通訊和控制問題，為多業務場景設計，複雜系統構建和中臺業務架構方案提供了全新的實現思路。利用智能代理xPort實現的業務間互聯互通，將對大型業務系統構建和擁有複雜業務邏輯的核心繫統研發帶來革命性的改變：
1. 業務架構簡單化 – 複雜業務結構通過xPort接入方式進行解耦，快速實現應用模塊化。
2. 以組織形態看待業務，而不是進行龐大臃腫的大架構設計。
3. 通過智能代理，業務間不再考慮統一設計，而是分立設計，甚至進行動態業務邏輯設計，彼此相互聯繫又各自獨立。
4. 智能代理所形成的分佈式業務群可實現快速部署，快速遷移。
5. 通過智能代理，可實現異構開發語言間的相互通訊。
6. 系統從集中式設計變成網絡化，節點化的分佈式設計，可無限延申業務體系。
7. 智能代理的分佈式接入架構對傳統的PaaS集中接入式架構發起了挑戰，但成本更低，新業務接入迅速，舊業務系統無需推倒重來。
閱讀更多 西部大視界 的文章
