Microservices==>Service Mesh==>Serverless，蜻蜓點水

時間 2021-08-13

標籤程序員數據庫編程服務器架構併發負載均衡 less 運維編程語言欄目快樂工作简体版

原文原文鏈接

[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] 合久必分less

起初項目比較小，系統功能不復雜，全部功能集成在一個項目工程中，全部功能打包成一個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內解決容器啓動、請求接入

事件驅動