近幾年的的微服務概念大火特火，隨之框架也變得大火起來，尤其是spring boot，可能是因為spring cloud火起來的原因 搞得沉寂多年的dubbo也開始更新變得火起來。 說起微服務對於不瞭解整個系統架構歷史的小伙伴可能有些迷惑，怎麼就突然一下子就微服務了，有點摸不著頭腦，到底咋回事那？聽我 ...
近幾年的的微服務概念大火特火，隨之框架也變得大火起來，尤其是spring boot，可能是因為spring cloud火起來的原因 搞得沉寂多年的dubbo也開始更新變得火起來。
說起微服務對於不瞭解整個系統架構歷史的小伙伴可能有些迷惑，怎麼就突然一下子就微服務了，有點摸不著頭腦，到底咋回事那？聽我娓娓道來！
很久很久以前的程式員都很牛逼一不開心就自己寫個操作系統自己玩，玩著玩著最後就剩下了幾個，比如我們熟知的windows，linux，蘋果OS，這是我們使用最底層的
操作系統，在操作系統上面我們還要運行我們的應用軟體，這個運行的應用軟體就是我們今天重點講解的，然而這個軟體一般指企業級軟體。
企業級軟體最初只想把那些紙質的數據進行電子化，但是不斷的發展，不斷的發展，不過也就幾十年的時間就出現瞭如下的架構（原諒我上面墨跡了那麼多沒用的）：
通過上面的發展我們我不在一一討論除微服務之外的各種優缺點，直奔主題，為什麼要用微服務？？
用三個字回答就是“可擴展”，圍繞可擴展我們最終實現了微服務化，以及實現了對應的實例框架 spring boot 等
也就是說，如果 “可擴展” 是抽象類的話，那麼微服務就是繼承了可擴展並實例化了（原諒我的程式思維）！
可擴展也是很直白，那就是可以根據實際需要進行擴展。最後很多牛叉的人和組織總結了一個AKF可擴展的立方體
X,Y,Z軸分別代表了不同的擴展方向，下麵簡單解釋一下：
X軸代表無差別的克隆服務和資料庫。用一個人來說X軸的例子可能是公司很多相同的事情分給多個人來乾，簡單快捷
在每個克隆實體間無差別的分配任務，每個克隆實體都可以完成其他克隆實體的任務，無論任務分配給了誰。
每個克隆實體都有工具和資源來儘快完成所分配的任務。
Y軸代表的是按照交易處理的數據類型，交易任務類型或兩者組合分割的工作責任。我們一般用動詞或資源進行分離，比如：
登錄，查詢，結算等等。把同樣的工作分割成流水線式的工作流或並行的處理流，Y軸代表的更多是對工作的“工業革命”，將耦合緊密的
工作進行進行專門處理。Y軸實質代表責任、行動或數據。實施成本一般比X軸擴展代價高。假如有100個人造100輛車，每個人負責
造一輛，完成造車全部的任務，不如讓100個人執行子任務，如發送機的安裝、噴漆、四輪定位。這樣就會減少前後交互所需要的上下文
信息，更專註做某件事情。
Z軸通常基於請求或客戶的信息進行分割。比如我們在分客戶時會有 “普通會員”和“vip會員“之分，服務“普通會員”與服務“vip會員”可能
會有不同。vip會員可能會特殊對待，會有單獨的人在處理vip會員的事情。但是他們都是會員。再比如一些客戶可能需要專門的賬單、
付款條件和基於業務量的特別互動。我們可能安排最好的財務代表、甚至特別的經理負責一個或多個客戶，以專門處理他們的獨特需求。
這樣將減少執行絕大多數的計費功能所需的知識量，從而服務好廣大客戶。
Z軸分割是成本最高的分割方向，Z軸分割有助於提高交易和數據的可擴展性，如果實施得當也有助於擴展指令集和過程
好下麵列舉一下按三個軸劃分的例子
X軸一般就是負載均衡，比如用F5等硬體設備進行埠輪訓負載。
Y軸主要體現在我們按業務拆分服務，比如登錄服務，訂單服務等
Z軸主要是對一些有特殊要求的業務執行單獨流程處理，比如按地區提供對應地區客戶的服務，根據不同地區不同客戶群的生活習慣等進行差異化服務。
下麵的圖會直觀一點
AKF擴展立方體XYZ三個軸可以根據實際情況酌情使用其中一個兩個或三個都是用，並且三個軸既可以無限向下擴展也可以無限向上擴展。
我們在設計系統架構的時候可以將AKF擴展立方體作為理論指導，設計完之後回過頭來看看是否可以做相應的擴展。
