[0] 始有道
話說圖靈開天闢地，馮.諾伊曼造石補天！
始有道
道生ML Machine Language
ML生彙編 assembler
彙編生編譯器 compiler
編譯器生PL Programming Language
後50年業務程式語言起，浩浩湯湯！
龜叔造Python,因為 人生苦短
Rasmus 造PHP，因為 PHP 世界上
松本行弘，不是很高興，因為他注意到其他程式設計師不是很高興。他建立了 Ruby 來讓程式設計師高興。
Brendan Eich 利用週末時間設計了一門語言，三易其名。LiveScript==>JavaScript==>ECMAScript
James Gosling 發明了 Java，從此天下門生半數盡入其彀中
Anders Hejlsberg 重新發明了 Java 然後把它叫做 C#，人們都喜歡這個新版本的 Java，因為它完全不像 Java。
一時間百家爭鳴、百花齊放，計算機江湖，風雲突起，各種設計、架構、模式豪傑並起、層出不窮、群雄逐鹿、熙熙攘攘
夫天下大勢分久必合、合久必分
系統架構莫不如是
且聽小生慢慢道來
[1] 合久必分
起初專案比較小，系統功能不復雜，所有功能整合在一個專案工程中，所有功能打包成一個WAR包部署，應用服務與資料庫服務分開部署，通過叢集來提高系統效能，此乃單體架構！
優點：專案架構簡單，前期開發成本低，週期短，小型專案的首選。
缺點：開發效率低，所有的開發在一個專案改程式碼，遞交程式碼相互等待，程式碼衝突不斷
缺點：程式碼維護難，程式碼功能耦合在一起，新人不知道何從下手
缺點：部署不靈活，構建時間長，任何小修改必須重新構建整個專案
缺點：穩定性不高，一個微不足道的小問題，可以導致整個應用掛掉
缺點：擴充套件性不夠，無法滿足高併發情況下的業務需求
噫籲嚱！為之奈何？
——分而治之，微服務
那什麼是微服務呢？
此處爭議較多！
此處不可描述！
此處略去800字！
此處大家不要想歪了！
此處大家還是看圖算了！
微服務的定義，沒有共識，但常見微服務元件還是清晰的
服務註冊：服務提供方將自己呼叫地址註冊到服務註冊中心，讓服務呼叫方能夠方便地找到自己。
服務閘道器：服務閘道器是服務呼叫的唯一入口，可以在這個元件是實現使用者鑑權、動態路由、灰度釋出、A/B 測試、負載限流等功能。
服務發現：服務呼叫方從服務註冊中心找到自己需要呼叫的服務的地址。
配置中心：將本地化的配置資訊（properties, xml, yaml 等）註冊到配置中心，實現程式包在開發、測試、生產環境的無差別性，方便程式包的遷移。
API 管理：以方便的形式編寫及更新 API 文件，並以方便的形式供呼叫者檢視和測試。
負載均衡：服務提供方一般以多例項的形式提供服務，負載均衡功能能夠讓服務呼叫方連線到合適的服務節點。節點選擇的工作對服務呼叫方來說是透明的。
分散式事務：對於重要的業務，需要通過分散式事務技術（TCC、高可用訊息服務、最大努力通知）保證資料的一致性。
呼叫鏈：記錄完成一個業務邏輯時呼叫到的微服務，並將這種序列或並行的呼叫關係展示出來。在系統出錯時，可以方便地找到出錯點。
支撐平臺：系統微服務化後，系統變得更加碎片化，系統的部署、運維、監控等都比單體架構更加複雜，那麼，就需要將大部分的工作自動化。現在，可以通過 Docker、K8S等工具來中和這些微服務架構帶來的弊端。 例如持續整合、藍綠髮布、健康檢查、效能健康等等。
那微服務又有什麼優缺點呢？
優點又很多，比如
降低系統複雜度：每個服務都比較簡單，只關注於一個業務功能。
鬆耦合：微服務架構方式是鬆耦合的，每個微服務可由不同團隊獨立開發，互不影響。
跨語言：只要符合服務 API 契約，開發人員可以自由選擇開發技術。
獨立部署：微服務架構可以使每個微服務獨立部署。開發人員無需協調對服務升級或更改的部署。
Docker 容器：和 Docker 容器結合的更好。
DDD 領域驅動設計：和 DDD 的概念契合，要兩顆一起嚼才最好。
缺點也不少，如下
微服務強調了服務大小，但實際上這並沒有一個統一的標準：業務邏輯應該按照什麼規則劃分為微服務，這本身就是一個經驗工程。
微服務的分散式特點帶來的複雜性：開發人員需要基於 RPC 或者訊息實現微服務之間的呼叫和通訊，而這就使得服務之間的發現、服務呼叫鏈的跟蹤和質量問題變得的相當棘手。
分割槽的資料庫體系和分散式事務：更新多個業務實體的業務交易相當普遍，不同服務可能擁有不同的資料庫。CAP 原理的約束，使得我們不得不放棄傳統的強一致性，而轉而追求最終一致性，這個對開發人員來說是一個挑戰。
測試挑戰：傳統的單體WEB應用只需測試單一的 REST API 即可，而對微服務進行測試，需要啟動它依賴的所有其他服務。這種複雜性不可低估。
跨多個服務的更改：比如在傳統單體應用中，若有 A、B、C 三個服務需要更改，A 依賴 B，B 依賴 C。我們只需更改相應的模組，然後一次性部署即可。但是在微服務架構中，我們需要仔細規劃和協調每個服務的變更部署。我們需要先更新 C，然後更新 B，最後更新 A。
部署複雜：微服務由不同的大量服務構成。每種服務可能擁有自己的配置、應用例項數量以及基礎服務地址。這裡就需要不同的配置、部署、擴充套件和監控元件。此外，我們還需要服務發現機制，以便服務可以發現與其通訊的其他服務的地址。
還有一個更大的槽點：目標介面、鏈路跟蹤注入、日誌引流、服務註冊發現、路由規則等元件以及熔斷、限流等功能都需要在應用服務上新增一些對接程式碼。如果讓每個應用服務自己實現是非常耗時耗力的，而且也不符合DRY原則
可有良策？且聽下回書“李代桃僵”
[2] 李代桃僵
K8S最小的排程單元為什麼是Pod,而不是容器？
我不打算回答這個問題，因為我是
，我也不知道。主要記住pod有以下主要特點
利用Pod的以下特點，我門可以把非業務功能，系統型的公共功能外包出去，交給“李子樹”，此乃服務網格是也！
話不多說，上圖
思考題：微服務，已經夠微小了嗎？這是個問題，Let us see see!
[3] 至小無內——Server less
Server less主要有以下特徵：
無常駐伺服器，200MS內解決容器啟動、請求接入
事件驅動
單事件處理
自動彈性伸縮
無狀態開發
思考題：服務還能更小嗎？都小到一個函式了，難道還要小到0.1個函式？
[4] 分久必合
既然不能再小了，不如更大、更高、更強？
Istio 從1.5 開始，迴歸單體！
Segment從微服務迴歸單體！！
是輪迴，是宿命，還是註定？看來果真天下大勢分久必合、合久必分。
濤濤江水東流去，無法阻止，那隻能隨波逐流，看來是時候著手搭建一個ServiceMesh 實驗室了！