[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 實驗室了！