微服務架構并無標準架構，不然什么架構師大會也不會各個系統架構百花齊放了，雖然沒有固定的套路，卻有一些經驗，今天就來做一個總結，
基于角色拆分
這種拆分方式常見于基礎設施以及其PaaS層的架構，比如服務治理、k8s、kafka，所謂基礎組件的PaaS層是說，基礎設施本身主要作為基礎設施使用，是IaaS層，但是基礎設施本身需要維護功能，需要增刪改查等運維操作，業界基于開源做的二次開發也著重在做這方面的作業，
下面以kafka做說明，因為要上升到PaaS層，下圖基于美團對kafka的二次開發封裝，產品名叫mafka，
咱們直接看★標注的部分mafka-manager，這個就是運維操作統一管理端，充當的就是管理者的角色，再看看kafka其他組件的名稱：生產者( producer )、消費者( consumer )、經紀人( broker )，核查員( monitor )，架構的組織都是根據角色來來劃分的，
為什么我要將mafka-manager用★標注呢，因為不管是基礎設施還是別的，以產品化的觀點，需要對外提供一個完整的產品體驗，完整的產品包含什么呢？統一的產品外觀、統一的介面定義、統一的服務運營，
我們要接入mafka，雖然最終程式里要用的是生產者、消費者這些，但是第一步都要在mafka-manager對應的界面上申請，mafka-manager類似于網關入口的角色，業界有專門把這些介面服務抽象出來叫做api網關，
在k8s架構中，api網關這個概念更加明顯一些，
kubectl是k8s的控制臺命令互動界面、web UI是瀏覽器互動界面，不同的互動界面會走統一的api server，這里api server就是api網關服務，
基于可擴展性拆分
首先來了解一下AKF擴展立方體，
AKF擴展立方體（Scalability Cube），是《架構即未來》一書中提出的可擴展模型，這個立方體有三個軸線，每個軸線描述擴展性的一個維度：
X軸 —— 代表無差別的克隆服務和資料，作業可以很均勻的分散在不同的服務實體上；
Y軸 —— 關注應用中職責的劃分，比如資料型別，交易執行型別的劃分；
Z軸 —— 關注服務和資料的優先級劃分，如分地域劃分，
白話來說：X軸拆分就是通過加機器水平拆分；Y軸拆分就是按業務邏輯垂直拆分；Z軸拆分就是按照演算法進行分片，這個演算法比如按地域，不同地域訪問不同的分片或者服務，
舉個例子，比如一般公司的redis集群會有一個團隊來進行統一維護，redis集群有主有從，資料都是一樣的，多副本容災，這是X軸水平的拆分，一個公司很多業務，redis團隊會對不同的業務提供不同的集群，這是Y軸垂直拆分；集群內部資料會通過sharding做分片，這是Z軸演算法拆分，
基于穩定性拆分
在業務架構中，通常會通過核心模塊的劃分或者主次鏈路的劃分來進行微服務拆分，
在《三平面分離架構》中，我提到過分離出控制平面、資料平面和管理平面，這本質上也是通過核心模塊劃分來進行拆分的一種方式，控制平臺一般是核心鏈路，核心資料作為控制邏輯的一部分可以通過本地快取等措施弱依賴于資料平面，管理平臺是后臺管理等，用于增刪改查，人工操作時才用，其他時間掛掉都沒關系，
基于資源需求拆分
根據性能需求來進行拆分，簡單來說就是訪問量特別大，訪問頻率特別高的業務，又要保證高效的回應能力，這些業務對性能的要求特別高，比如積分競拍、低價秒殺、限量搶購，
我們要識別出某些超高并發量的業務，盡可能把這部分業務獨立拆分出來，這么做的原因非常簡單，一個保證滿足高性能業務需求，另一個保證業務的獨立性，不互相影響，
類似積分競拍、超低價秒殺、限量搶購，對瞬間峰值和計算性能要求是非常高的，這部分的業務如果跟其他通用業務放在一塊，一個是可能互相影響，比如某個鏈路阻塞，會導致雪崩沿呼叫鏈向上傳遞，
另外一個是如果多個業務耦合在一塊，發布頻率變高、服務擴縮容變難、維護復雜度變高，如下圖例子所示，訂單服務是一個性能要求高的服務，一般會單獨拆分，
總結
咱們實際作業中，通常會發現一種拆分方式和另一種拆分方式并不沖突，一個完整的架構也不只使用了一種拆分方式，《領域驅動設計(DDD)中簡單易用的10種技巧》也可以配合來使用，
本文提到的api網關嚴格上不是業務劃分時的一個模塊，業界通常把api網關作為一個基礎設施，如果在架構圖中包含了api網關通常是下圖所示：
上圖中的架構既包含了業務邏輯的業務劃分，也有配置中心、注冊中心這樣的技識訓分，總體上來說是一個技術架構圖，而api網關本身也更多被歸為是技術概念，而不是業務概念，
在《尤娜系統的第一次飛行中換引擎的架構垂直拆分改造》中，首先就拆分出來了api網關層，這說明尤娜要下一盤大棋，最終對外會提供一個統一的產品，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/437061.html
標籤：其他