kubernetes

kubernetes，簡稱K8s，是用8代替8個字符“ubernete”而成的縮寫。是一個開源的，用於管理雲平臺中多個主機上的容器化的應用，Kubernetes的目標是讓部署容器化的應用簡單並且高效（powerful）,Kubernetes提供了應用部署，規劃，更新，維護的一種機制。

傳統的應用部署方式是通過插件或腳本來安裝應用。這樣做的缺點是應用的運行、配置、管理、所有生存週期將與當前操作系統綁定，這樣做並不利於應用的升級更新/回滾等操作，當然也可以通過創建虛擬機的方式來實現某些功能，但是虛擬機非常重，並不利於可移植性。

新的方式是通過部署容器方式實現，每個容器之間互相隔離，每個容器有自己的文件系統，容器之間進程不會相互影響，能區分計算資源。相對於虛擬機，容器能快速部署，由於容器與底層設施、機器文件系統解耦的，所以它能在不同雲、不同版本操作系統間進行遷移。

容器佔用資源少、部署快，每個應用可以被打包成一個容器鏡像，每個應用與容器間成一對一關係也使容器有更大優勢，使用容器可以在build或release 的階段，爲應用創建容器鏡像，因爲每個應用不需要與其餘的應用堆棧組合，也不依賴於生產環境基礎結構，這使得從研發到測試、生產能提供一致環境。類似地，容器比虛擬機輕量、更“透明”，這更便於監控和管理。

Kubernetes概述

Kubernetes是Google開源的一個容器編排引擎，它支持自動化部署、大規模可伸縮、應用容器化管理。在生產環境中部署一個應用程序時，通常要部署該應用的多個實例以便對應用請求進行負載均衡。

在Kubernetes中，我們可以創建多個容器，每個容器裏面運行一個應用實例，然後通過內置的負載均衡策略，實現對這一組應用實例的管理、發現、訪問，而這些細節都不需要運維人員去進行復雜的手工配置和處理。

Kubernetes 特點

可移植: 支持公有云，私有云，混合雲，多重雲（multi-cloud）
可擴展: 模塊化，插件化，可掛載，可組合
自動化: 自動部署，自動重啓，自動複製，自動伸縮/擴展

Kubernetes節點

在這張系統架構圖中，我們把服務分爲運行在工作節點上的服務和組成集羣級別控制板的服務。

Kubernetes節點有運行應用容器必備的服務，而這些都是受Master的控制。

每次個節點上當然都要運行Docker。Docker來負責所有具體的映像下載和容器運行。

Kubernetes主要由以下幾個核心組件組成：

etcd保存了整個集羣的狀態；
apiserver提供了資源操作的唯一入口，並提供認證、授權、訪問控制、API註冊和發現等機制；
controller manager負責維護集羣的狀態，比如故障檢測、自動擴展、滾動更新等；
scheduler負責資源的調度，按照預定的調度策略將Pod調度到相應的機器上；
kubelet負責維護容器的生命週期，同時也負責Volume（CVI）和網絡（CNI）的管理；
Container runtime負責鏡像管理以及Pod和容器的真正運行（CRI）；
kube-proxy負責爲Service提供cluster內部的服務發現和負載均衡；

除了核心組件，還有一些推薦的Add-ons：

kube-dns負責爲整個集羣提供DNS服務
Ingress Controller爲服務提供外網入口
Heapster提供資源監控
Dashboard提供GUI
Federation提供跨可用區的集羣
Fluentd-elasticsearch提供集羣日誌採集、存儲與查詢

分層架構

Kubernetes設計理念和功能其實就是一個類似Linux的分層架構，如下圖所示

核心層：Kubernetes最核心的功能，對外提供API構建高層的應用，對內提供插件式應用執行環境
應用層：部署（無狀態應用、有狀態應用、批處理任務、集羣應用等）和路由（服務發現、DNS解析等）
管理層：系統度量（如基礎設施、容器和網絡的度量），自動化（如自動擴展、動態Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
接口層：kubectl命令行工具、客戶端SDK以及集羣聯邦
生態系統：在接口層之上的龐大容器集羣管理調度的生態系統，可以劃分爲兩個範疇
- Kubernetes外部：日誌、監控、配置管理、CI、CD、Workflow、FaaS、OTS應用、ChatOps等
- Kubernetes內部：CRI、CNI、CVI、鏡像倉庫、Cloud Provider、集羣自身的配置和管理等

kubelet

kubelet負責管理pods和它們上面的容器，images鏡像、volumes、etc。

kube-proxy

每一個節點也運行一個簡單的網絡代理和負載均衡（詳見services FAQ )（PS:官方英文）。正如Kubernetes API裏面定義的這些服務（詳見the services doc）（PS:官方英文）也可以在各種終端中以輪詢的方式做一些簡單的TCP和UDP傳輸。

服務端點目前是通過DNS或者環境變量( Docker-links-compatible 和 Kubernetes{FOO}_SERVICE_HOST 及 {FOO}_SERVICE_PORT 變量都支持)。這些變量由服務代理所管理的端口來解析。

Kubernetes控制面板

Kubernetes控制面板可以分爲多個部分。目前它們都運行在一個master 節點，然而爲了達到高可用性，這需要改變。不同部分一起協作提供一個統一的關於集羣的視圖。

etcd

所有master的持續狀態都存在etcd的一個實例中。這可以很好地存儲配置數據。因爲有watch(觀察者)的支持，各部件協調中的改變可以很快被察覺。

Kubernetes API Server

API服務提供Kubernetes API （PS:官方英文）的服務。這個服務試圖通過把所有或者大部分的業務邏輯放到不兩隻的部件中從而使其具有CRUD特性。它主要處理REST操作，在etcd中驗證更新這些對象（並最終存儲）。

Scheduler

調度器把未調度的pod通過binding api綁定到節點上。調度器是可插拔的，並且我們期待支持多集羣的調度，未來甚至希望可以支持用戶自定義的調度器。

Kubernetes控制管理服務器

所有其它的集羣級別的功能目前都是由控制管理器所負責。例如，端點對象是被端點控制器來創建和更新。這些最終可以被分隔成不同的部件來讓它們獨自的可插拔。

replicationcont roller（PS:官方英文）是一種建立於簡單的 pod API之上的一種機制。一旦實現，我們最終計劃把這變成一種通用的插件機制。

Prometheus

Prometheus是由SoundCloud開發的開源監控報警系統和時序列數據庫(TSDB)。Prometheus使用Go語言開發，是Google BorgMon監控系統的開源版本。
2016年由Google發起Linux基金會旗下的原生雲基金會(Cloud Native Computing Foundation), 將Prometheus納入其下第二大開源項目。
Prometheus目前在開源社區相當活躍。
Prometheus和Heapster(Heapster是K8S的一個子項目，用於獲取集羣的性能數據。)相比功能更完善、更全面。Prometheus性能也足夠支撐上萬臺規模的集羣。

Prometheus的特點

多維度數據模型。
靈活的查詢語言。
不依賴分佈式存儲，單個服務器節點是自主的。
通過基於HTTP的pull方式採集時序數據。
可以通過中間網關進行時序列數據推送。
通過服務發現或者靜態配置來發現目標服務對象。
支持多種多樣的圖表和界面展示，比如Grafana等。

基本原理

Prometheus的基本原理是通過HTTP協議週期性抓取被監控組件的狀態，任意組件只要提供對應的HTTP接口就可以接入監控。不需要任何SDK或者其他的集成過程。這樣做非常適合做虛擬化環境監控系統，比如VM、Docker、Kubernetes等。輸出被監控組件信息的HTTP接口被叫做exporter 。目前互聯網公司常用的組件大部分都有exporter可以直接使用，比如Varnish、Haproxy、Nginx、MySQL、Linux系統信息(包括磁盤、內存、CPU、網絡等等)。

服務過程

Prometheus Daemon負責定時去目標上抓取metrics(指標)數據，每個抓取目標需要暴露一個http服務的接口給它定時抓取。Prometheus支持通過配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目標。Prometheus採用PULL的方式進行監控，即服務器可以直接通過目標PULL數據或者間接地通過中間網關來Push數據。
Prometheus在本地存儲抓取的所有數據，並通過一定規則進行清理和整理數據，並把得到的結果存儲到新的時間序列中。
Prometheus通過PromQL和其他API可視化地展示收集的數據。Prometheus支持很多方式的圖表可視化，例如Grafana、自帶的Promdash以及自身提供的模版引擎等等。Prometheus還提供HTTP API的查詢方式，自定義所需要的輸出。
PushGateway支持Client主動推送metrics到PushGateway，而Prometheus只是定時去Gateway上抓取數據。
Alertmanager是獨立於Prometheus的一個組件，可以支持Prometheus的查詢語句，提供十分靈活的報警方式。

三大套件

Server 主要負責數據採集和存儲，提供PromQL查詢語言的支持。
Alertmanager 警告管理器，用來進行報警。
Push Gateway 支持臨時性Job主動推送指標的中間網關。

微服務

傳統的it架構的缺陷：

使用傳統的整體式架構(Monolithic Architecture)應用開發系統，如CRM、ERP等大型應用，隨着新需求的不斷增加，企業更新和修復大型整體式應用變得越來越困難；

隨着移動互聯網的發展，企業被迫將其應用遷移至現代化UI界面架構以便能兼容移動設備，這要求企業能實現應用功能的快速上線；

許多企業在SOA投資中得到的回報有限，SOA可以通過標準化服務接口實現能力的重用，但對於快速變化的需求，受到整體式應用的限制，有時候顯得力不從心；

二、什麼是微服務？

微服務是一種架構風格，一個大型複雜軟件應用由一個或多個微服務組成。系統中的各個微服務可被獨立部署，各個微服務之間是松耦合的。每個微服務僅關注於完成一件任務並很好地完成該任務。在所有情況下，每個任務代表着一個小的業務能力。

可以在“自己的程序”中運行，並通過“輕量級設備與HTTP型API進行溝通”。關鍵在於該服務可以在自己的程序中運行。通過這一點我們就可以將服務公開與微服務架構（在現有系統中分佈一個API）區分開來。在服務公開中，許多服務都可以被內部獨立進程所限制。如果其中任何一個服務需要增加某種功能，那麼就必須縮小進程範圍。在微服務架構中，只需要在特定的某種服務中增加所需功能，而不影響整體進程。

1.1 產品現狀

1、各產品系統獨立開發，代碼複用率低，系統之間互相調用，耦合嚴重，系統解耦獨立部署困難。
2、傳統的單體架構，規模越來越大也越來越笨重；當新功能的開發、功能的重構變得不再敏捷可控；測試者的迴歸測試邊界難以琢磨；系統的上線部署也變的艱難
3、高併發訪問下無法提供可靠性服務
4、持續集成、持續部署、持續交付等工程效率化工具嚴重缺失
5、監控系統、日誌分析等系統穩定性工具嚴重缺失
以上種種情況，都讓我們應對需求的變化而變得遲鈍。

1.2 業務需求

架構肯定是爲業務需求而生的，先來看看我們面對的業務需求及其特點。平臺最主要滿足兩大類業務需求：面向餐飲企業在餐飲新零售下的經營和運營需求和麪向產品及運營團隊。
具體來看：
1、餐飲新零售下的餐飲企業經營和運營的痛點

如何提升營銷能力和管理會員，以更低的成本爲餐飲企業帶來更多利潤
如何對數據進行深度挖掘和分析，助力決策者進行運營決策
如何掌握實時數據，讓決策者及時瞭解餐廳運營情況

2、面向產品及運營團隊

主要是提升產品控制能力，促進整體系統的良好運轉

因此開發SAAS服務的產品迫在眉睫，需要滿足快速開發、靈活升級、高性能、高可用、高穩定、簡化運維等更高的需求。

這一步的轉型，不是"快"與"慢"，而是"生"與"死"。

二、微服務概念

專注於單一責任與功能獨立運行的服務，模組化方式組合出大型應用。

2.1 特點

集中式架構：單體無分散
分佈式架構：分散壓力
微服務架構：分散能力

2.2 微服務架構優勢

每個微服務組件都是簡單靈活的，能夠獨立部署。不再像單體應用時代，應用需要一個龐大的應用服務器來支撐。
可以由一個小團隊負責更專注專業，相應的也就更高效可靠。
微服務之間是松耦合的，微服務內部是高內聚的，每個微服務很容易按需擴展。

三、微服務技術選型和微服務的問題

3.1 技術選型

3.1.1 技術矩陣結論

Netflix提供了比較全面的解決方案
Spring Cloud對於Netflix的封裝比較全面
Spring Cloud基於Spring Boot，團隊有基礎
Spring Cloud提供了Control Bus能夠幫助實現監控埋點
業務應用部署在阿里雲，Spring Cloud對12 Factors以及Cloud-Native的支持，有利於在雲環境下使用

3.1.2 團隊期望

首先支持Rest
團隊技術棧和實例比較單薄，希望對新的技術平滑的學習曲線和能夠Hold住
小團隊，希望能夠有一個比較全面的解決方案
目前團隊主要採用Spring Cloud + Spring Boot的方式實現服務化

有關技術選型詳細分析，請查看我的上一篇文章《我的技術選型》。

3.2 微服務帶來的問題

依賴服務變更很難跟蹤，其他團隊的服務接口文檔過期怎麼辦？依賴的服務沒有準備好，如何驗證我開發的功能。
部分模塊重複構建，跨團隊、跨系統、跨語言會有很多的重複建設。
微服務放大了分佈式架構的系列問題，如分佈式事務怎麼處理？依賴服務不穩定怎麼辦？
運維複雜度陡增，如：部署物數量多、監控進程多導致整體運維複雜度提升。

上面這些問題我們應該都遇到過，並且總結形成了自己的一些解決方案，比如提供文檔管理、服務治理、服務模擬的工具和框架；實現統一認證、統一配置、統一日誌框架、分佈式彙總分析；採用全局事務方案、採用異步模擬同步；搭建持續集成平臺、統一監控平臺等等。

微服務架構是一把雙刃劍，雖然解決了集中式架構和分佈式架構的問題，卻帶來了如上種種問題。因此我們是需要一個微服務應用平臺才能整體性的解決這些問題。

四、微服務架構設計

4.1 微服務應用架構設計原則

4.2 微服務應用架構設計目標

微服務架構設計的目標，滿足快速開發、靈活升級、高性能、高可用、高穩定、簡化運維等更高的需求。

4.3 微服務應用總體架構

微服務應用平臺的總體架構，主要是從開發集成、微服務運行容器與平臺、運行時監控治理和外部渠道接入等維度來劃分和考慮的。

開發集成：主要是搭建一個微服務平臺需要具備的一些工具和倉庫
運行時：要有微服務平臺來提供一些基礎能力和分佈式的支撐能力，我們的微服務運行容器則會運行在這個平臺之上。
監控治理：則是致力於在運行時能夠對受管的微服務進行統一的監控、配置等能力。
服務網關：則是負責與前端的WEB應用移動APP 等渠道集成，對前端請求進行認證鑑權，然後路由轉發。

4.4 微服務框架概覽

這裏不詳細講解服務框架中每一個組件，另開一篇文章來講解。

五、微服務架構設計落地

5.1 基礎環境

一個企業的IT建設非常重要的三大基礎環境：團隊協作環境、服務基礎環境、IT基礎設施。

團隊協作環境：主要是DevOps領域的範疇，負責從需求到計劃任務，團隊協作，再到質量管理、持續集成和發佈。
服務基礎環境：指的是微服務應用平臺，其目標主要就是要支撐微服務應用的設計開發測試，運行期的業務數據處理和應用的管理監控。
IT基礎設施：主要是各種運行環境支撐如IaaS (VM虛擬化)和CaaS (容器虛擬化)等實現方式。

5.2 服務通信

服務間的通信，往往採用HTTP+REST 和 RPC通信協議。

HTTP+REST，對服務約束完全靠提供者的自覺。

特點是簡單，對開發使用友好。
缺點治理起來困難，連接的無狀態，缺失多路複用、服務端推送等。

RPC對通信雙方定義了數據約束。

連接大多基於長連接以獲得性能的提升及附帶的服務端推、調用鏈路監控埋點等，增強了系統的附加能力。
缺點是對調用端提出了新的要求。

綜合來看，RPC從性能、契約優先來說具有優勢，如何做到揚長避短呢？
引入GateWay層，讓REST與RPC的優點進行融合，在GateWay層提供REST的接入能力。

5.3 服務註冊/發現

以前的單體應用之間互相調用時配置個IP或域名就行了，但在微服務架構下，服務提供者會有很多，手工配置IP地址或域名又變成了一個耦合和繁瑣的事情。那麼服務自動註冊發現的方案就解決了這個問題。
我們的服務註冊發現能力是依賴SpringCloud Eureka組件實現的。服務在啓動的時候，會將自己要發佈的服務註冊到服務註冊中心；運行時，如果需要調用其他微服務的接口，那麼就要先到註冊中心獲取服務提供者的地址，拿到地址後，通過微服務容器內部的簡單負載均衡期進行路由用。

Eureka Server特點：

Eureka Client會緩存服務註冊信息
Eureka Server的註冊信息只存儲在內存中
Eureka的註冊只針對application級別，不支持更細粒度的服務註冊，如單個服務Rest
服務每隔30秒向Eureka Server發送心跳，不建議修改心跳時間。Eureka用這個時間來判斷集羣內是否存在大範圍的服務通信異常
如果在15分鐘內有85%的服務沒有被續約，則Eureka Server停止移除已註冊的服務，以保障已註冊的服務信息不丟失
Eureka Server之間的數據同步，採用全量拉取，增量同步的方式
Eureka 滿足分佈式事務中的CAP理論中的AP

5.4 集中式配置管理

微服務分佈式環境下，一個系統拆分爲很多個微服務，一定要告別運維手工修改配置配置的方式。需要採用集中配置管理的方式來提升運維的效率。
配置文件主要有運行前的靜態配置和運行期的動態配置兩種。

靜態配置通常是在編譯部署包之前設置好。
動態配置則是系統運行過程中需要調整的系統變量或者業務參數。

要想做到集中的配置管理，那麼需要注意以下幾點。

配置與介質分離，這個就需要通過制定規範的方式來控制。
配置的方式要統一，格式、讀寫方式、變更熱更新的模式儘量統一，要採用統一的配置框架。
需要運行時需要有個配置中心來統一管理業務系統中的配置信息。

概念抽象：
介質，是源碼編譯後的產物與環境無關，多環境下應該是可以共用的如：jar

5.5 統一認證鑑權

安全認證方面，我們基於Spring Security OAuth2 + JWT做安全令牌，實現統一的安全認證與鑑權，使得微服務之間能夠按需隔離和安全互通。
認證鑑權一定是個公共的服務，而不是多個系統各自建設。

5.6 分佈式調用

微服務架構下，相對於傳統部署方式，存在更多的分佈式調用，那麼“如何在不確定的環境中交付確定的服務”，這句話可以簡單理解爲，我所依賴的服務的可靠性是無法保證的情況下，我如何保證自己能夠正常的提供服務，不被我依賴的其他服務拖垮？
我們採用的方案：

合理的超時時間
合理的重試機制
合理的異步機制
合理的限流機制（調用次數和頻率）
合理的降級機制
合理的熔斷機制

推薦SEDA架構來解決這個問題。
SEDA : staged event-driven architecture本質上就是採用分佈式事件驅動的模式，用異步模擬來同步，無阻塞等待，再加上資源分配隔離結起來的一個解決方案。

5.7 分佈式事務

分佈式事務-CAP

C 分佈式環境下多個節點的數據是否強一致
A 分佈式服務能一直保證可用狀態
P 網絡分區的容錯性

分佈式事務-策略

避免跨庫事務，儘可能相關表在同一個DB
2PC 3PC TCC 補償模式等，耗時且複雜
基於MQ的最終一致性簡單、高效、易於理解
將遠程分佈式事務拆解成一系列本地的事務

分佈式事務-基於MQ

5.8 服務拆分

服務拆分方式

AKF擴展立方體，是抽象總結的應用擴展的三個維度。

X軸擴展部署實例，就是講單體系統多運行幾個實例，做個集羣加負載均衡的模式。
Y軸業務領域分離，就是基於不同的業務拆分。
Z軸數據隔離分區，比如共享單車在用戶量激增時，集羣模式撐不住了，那就按照用戶請求的地區進行數據分區，北京、上海、深圳等多建幾個集羣。

服務拆分要點

低耦合、高內聚：一個服務完成一個獨立的功能
按照團隊結構：小規模團隊維護，快速迭代

5.9 數據庫拆分

單庫單表難以支撐日益增長的業務量和數據量，服務拆分了數據庫也跟着拆分。

5.9.1 模式

垂直拆分
水平拆分

5.9.2 原則

儘可能不拆分
避免跨庫事務
單表量級1000w
避免垮褲join（冗餘、全局表）

5.10 日誌管理

日誌主要有三種，系統日誌，業務日誌，跟蹤日誌。有了這些日誌，在出問題的時候能夠幫助我們獲取一些關鍵信息進行問題定位。
要想做到，出了問題能夠追根溯源，那麼我們需要一個可以將整個完整的請求調用鏈串聯起來的標識，這個標識能夠讓我們快速定位問題發生的具體時間地點以及相關信息，能夠快速還原業務交易全鏈路。對這些日誌與流水的細節處理，對於系統運維問題定位有非常大的幫助。通常開源框架只是提供基礎的框架，而設計一個平臺則一定要考慮直接提供統一規範的基礎能力。

分佈式跟蹤

5.11 服務契約與API管理

對於前面提到的微服務帶來的依賴管理問題，我們需要提供API管理能力。說到API管理，那首先就用提到服務契約。
服務契約，主要描述服務接口的輸入輸出規格標準和其他一些服務調用集成相關的規格內容。

5.12 服務契約與服務模擬

有了服務契約，研發人員就可以方便的獲取到依賴服務變更的情況，能夠及時的根據依賴服務的變化調整自己的程序，並且能夠方便的進行模擬測試驗證。
根據契約生成模擬服務也就是我們常說的服務擋板，這樣即使依賴的其他服務還無法提供功能，我們也可以通過擋板來進行聯調測試。

5.13 微服務容器

我們要做穩定、高效、易擴展的微服務應用，實際上我們需要做的事情還是非常多的。如果沒有一個統一的微服務容器，這些能力在每個微服務組件中都需要建設一遍，也很難集成到一起。有了統一的微服務運行容器和一些公共的基礎服務，前面所提到的微服務架構下部分組件重複建設的問題也迎刃而解。

5.14 持續集成與持續部署

在運維方面，首先我們要解決的就是持續集成和持續交付，能夠方便的用持續集成環境把程序編譯成介質包和部署包並持續穩定的部署到每個環境。
概念抽象：
介質：是源碼編譯後的產物與環境無關，多環境下應該是可以共用的。如：jar
配置：則是環境相關的信息。
部署包=配置+介質。

5.15 微服務平臺與容器雲、DevOps的關係

就微服務應用平臺本身來說，並不依賴DevOps和容器雲，開發好的部署包可以運行在物理機、虛擬機或者是容器中。然而當微服務應用平臺結合了DevOps和容器雲之後，我們就會發現，持續集成和交付變成了一個非常簡單便捷並且又可靠的過程。簡單幾步操作，整套開發、測試、預發或者生產環境就能夠搭建完成。
整個過程的複雜度都由平臺給屏蔽掉了，通過三大基礎環境的整合，我們能夠使分散的微服務組件更簡單方便的進行統一管理和運維交付。

5.16 技術團隊的組織

技術團隊組織 – 小團隊

根據“康威定律”，軟件架構是由組織的架構決定的，因此按照貝索斯“two-pizza”團隊的理論和敏捷方法，構建小的團隊，可以有效減少溝通成本，有利於團隊的自治。
我們通過讓一個小的團隊有比較全面的建制，Leader（熟悉業務和技術）+ 前端工程師 + 後端工程師，往往可以能夠比較獨立地承接一個或者幾個業務的工作。這樣團隊成員整體負責一個或者幾個業務模塊，可以極大地提高團隊成員的參與感、使命感和責任感，團隊成員相互幫助，高度自治，大家要麼一起成功，要麼一起失敗。

技術團隊組織 – 團隊劃分

團隊的劃分，是按照業務線劃分的。隨着業務的複雜度的增加，可以按照業務/子業務線的方式來劃分團隊，但並不是絕對的扁平化，而是嚴格遵循two-pizza原則。
業務線的劃分常常按業務細分，技術團隊要負責支持全部業務線，因此技術團隊的劃分通常按系統或者是業務，Two pizza團隊的原則在組織層級的任何部分都適用，當人數過多時，必須繼續拆分。

技術團隊組織 – 團隊合作

技術團隊組織 – 結果導向

主人翁意識（Ownership）
行動力（Bias for Action）
喫自己的狗糧（Eat your dog food）
• 工程師負責從需求調研、設計、開發、測試、部署、維護、監控、功能升級等一系列的工作，也就是說軟件工程師負責應用或者服務的全生命週期的所有工作
• 運維是團隊成員的第一要務，在強大的自動化運維工具的支撐下，軟件工程師必須負責服務或者應用的SLA
開發人員參與架構設計，而不是架構師參與開發
• 研發人員是Owner，對業務和團隊負責
• 強調抽象和簡化，將複雜的問題分解成簡單的問題，並有效解決，避免過度設計
• 鼓勵用新技術解決問題，但強調掌控力

六、微服務架構設計過程中積累的心得

深入理解業務
設計階段要追求完美，實踐階段要考慮實際情況作出平衡
容錯能力
監控先行
任何上線可回滾

七、總結

微服務架構是技術升級，但更多的是管理模式的升級、思維方式的轉變。

LVS負載均衡（LVS簡介、三種工作模式、十種調度算法）

一、LVS簡介

LVS（Linux Virtual Server）即Linux虛擬服務器，是由章文嵩博士主導的開源負載均衡項目，目前LVS已經被集成到Linux內核模塊中。該項目在Linux內核中實現了基於IP的數據請求負載均衡調度方案，其體系結構如圖1所示，終端互聯網用戶從外部訪問公司的外部負載均衡服務器，終端用戶的Web請求會發送給LVS調度器，調度器根據自己預設的算法決定將該請求發送給後端的某臺Web服務器，比如，輪詢算法可以將外部的請求平均分發給後端的所有服務器，終端用戶訪問LVS調度器雖然會被轉發到後端真實的服務器，但如果真實服務器連接的是相同的存儲，提供的服務也是相同的服務，最終用戶不管是訪問哪臺真實服務器，得到的服務內容都是一樣的，整個集羣對用戶而言都是透明的。最後根據LVS工作模式的不同，真實服務器會選擇不同的方式將用戶需要的數據發送到終端用戶，LVS工作模式分爲NAT模式、TUN模式、以及DR模式。

二、三種工作模式的解析。

1、基於NAT的LVS模式負載均衡

NAT（Network Address Translation）即網絡地址轉換，其作用是通過數據報頭的修改，使得位於企業內部的私有IP地址可以訪問外網，以及外部用用戶可以訪問位於公司內部的私有IP主機。VS/NAT工作模式拓撲結構如圖2所示，LVS負載調度器可以使用兩塊網卡配置不同的IP地址，eth0設置爲私鑰IP與內部網絡通過交換設備相互連接，eth1設備爲外網IP與外部網絡聯通。

第一步，用戶通過互聯網DNS服務器解析到公司負載均衡設備上面的外網地址，相對於真實服務器而言，LVS外網IP又稱VIP（Virtual IP Address），用戶通過訪問VIP，即可連接後端的真實服務器（Real Server），而這一切對用戶而言都是透明的，用戶以爲自己訪問的就是真實服務器，但他並不知道自己訪問的VIP僅僅是一個調度器，也不清楚後端的真實服務器到底在哪裏、有多少真實服務器。

第二步，用戶將請求發送至124.126.147.168，此時LVS將根據預設的算法選擇後端的一臺真實服務器（192.168.0.1~192.168.0.3），將數據請求包轉發給真實服務器，並且在轉發之前LVS會修改數據包中的目標地址以及目標端口，目標地址與目標端口將被修改爲選出的真實服務器IP地址以及相應的端口。

第三步，真實的服務器將響應數據包返回給LVS調度器，調度器在得到響應的數據包後會將源地址和源端口修改爲VIP及調度器相應的端口，修改完成後，由調度器將響應數據包發送回終端用戶，另外，由於LVS調度器有一個連接Hash表，該表中會記錄連接請求及轉發信息，當同一個連接的下一個數據包發送給調度器時，從該Hash表中可以直接找到之前的連接記錄，並根據記錄信息選出相同的真實服務器及端口信息。

2、基於TUN的LVS負載均衡

在LVS（NAT）模式的集羣環境中，由於所有的數據請求及響應的數據包都需要經過LVS調度器轉發，如果後端服務器的數量大於10臺，則調度器就會成爲整個集羣環境的瓶頸。我們知道，數據請求包往往遠小於響應數據包的大小。因爲響應數據包中包含有客戶需要的具體數據，所以LVS（TUN）的思路就是將請求與響應數據分離，讓調度器僅處理數據請求，而讓真實服務器響應數據包直接返回給客戶端。VS/TUN工作模式拓撲結構如圖3所示。其中，IP隧道（IP tunning）是一種數據包封裝技術，它可以將原始數據包封裝並添加新的包頭（內容包括新的源地址及端口、目標地址及端口），從而實現將一個目標爲調度器的VIP地址的數據包封裝，通過隧道轉發給後端的真實服務器（Real Server），通過將客戶端發往調度器的原始數據包封裝，並在其基礎上添加新的數據包頭（修改目標地址爲調度器選擇出來的真實服務器的IP地址及對應端口），LVS（TUN）模式要求真實服務器可以直接與外部網絡連接，真實服務器在收到請求數據包後直接給客戶端主機響應數據。

3、基於DR的LVS負載均衡

在LVS（TUN）模式下，由於需要在LVS調度器與真實服務器之間創建隧道連接，這同樣會增加服務器的負擔。與LVS（TUN）類似，DR模式也叫直接路由模式，其體系結構如圖4所示，該模式中LVS依然僅承擔數據的入站請求以及根據算法選出合理的真實服務器，最終由後端真實服務器負責將響應數據包發送返回給客戶端。與隧道模式不同的是，直接路由模式（DR模式）要求調度器與後端服務器必須在同一個局域網內，VIP地址需要在調度器與後端所有的服務器間共享，因爲最終的真實服務器給客戶端迴應數據包時需要設置源IP爲VIP地址，目標IP爲客戶端IP，這樣客戶端訪問的是調度器的VIP地址，迴應的源地址也依然是該VIP地址（真實服務器上的VIP），客戶端是感覺不到後端服務器存在的。由於多臺計算機都設置了同樣一個VIP地址，所以在直接路由模式中要求調度器的VIP地址是對外可見的，客戶端需要將請求數據包發送到調度器主機，而所有的真實服務器的VIP地址必須配置在Non-ARP的網絡設備上，也就是該網絡設備並不會向外廣播自己的MAC及對應的IP地址，真實服務器的VIP對外界是不可見的，但真實服務器卻可以接受目標地址VIP的網絡請求，並在迴應數據包時將源地址設置爲該VIP地址。調度器根據算法在選出真實服務器後，在不修改數據報文的情況下，將數據幀的MAC地址修改爲選出的真實服務器的MAC地址，通過交換機將該數據幀發給真實服務器。整個過程中，真實服務器的VIP不需要對外界可見。

三、LVS負載均衡調度算法

根據前面的介紹，我們瞭解了LVS的三種工作模式，但不管實際環境中採用的是哪種模式，調度算法進行調度的策略與算法都是LVS的核心技術，LVS在內核中主要實現了一下十種調度算法。

1.輪詢調度

輪詢調度（Round Robin 簡稱'RR'）算法就是按依次循環的方式將請求調度到不同的服務器上，該算法最大的特點就是實現簡單。輪詢算法假設所有的服務器處理請求的能力都一樣的，調度器會將所有的請求平均分配給每個真實服務器。

2.加權輪詢調度

加權輪詢（Weight Round Robin 簡稱'WRR'）算法主要是對輪詢算法的一種優化與補充，LVS會考慮每臺服務器的性能，並給每臺服務器添加一個權值，如果服務器A的權值爲1，服務器B的權值爲2，則調度器調度到服務器B的請求會是服務器A的兩倍。權值越高的服務器，處理的請求越多。

3.最小連接調度

最小連接調度（Least Connections 簡稱'LC'）算法是把新的連接請求分配到當前連接數最小的服務器。最小連接調度是一種動態的調度算法，它通過服務器當前活躍的連接數來估計服務器的情況。調度器需要記錄各個服務器已建立連接的數目，當一個請求被調度到某臺服務器，其連接數加1；當連接中斷或者超時，其連接數減1。

（集羣系統的真實服務器具有相近的系統性能，採用最小連接調度算法可以比較好地均衡負載。)

4.加權最小連接調度

加權最少連接（Weight Least Connections 簡稱'WLC'）算法是最小連接調度的超集，各個服務器相應的權值表示其處理性能。服務器的缺省權值爲1，系統管理員可以動態地設置服務器的權值。加權最小連接調度在調度新連接時儘可能使服務器的已建立連接數和其權值成比例。調度器可以自動問詢真實服務器的負載情況，並動態地調整其權值。

5.基於局部的最少連接

基於局部的最少連接調度（Locality-Based Least Connections 簡稱'LBLC'）算法是針對請求報文的目標IP地址的負載均衡調度，目前主要用於Cache集羣系統，因爲在Cache集羣客戶請求報文的目標IP地址是變化的。這裏假設任何後端服務器都可以處理任一請求，算法的設計目標是在服務器的負載基本平衡情況下，將相同目標IP地址的請求調度到同一臺服務器，來提高各臺服務器的訪問局部性和Cache命中率，從而提升整個集羣系統的處理能力。LBLC調度算法先根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處於一半的工作負載，則使用'最少連接'的原則選出一個可用的服務器，將請求發送到服務器。

6.帶複製的基於局部性的最少連接

帶複製的基於局部性的最少連接（Locality-Based Least Connections with Replication 簡稱'LBLCR'）算法也是針對目標IP地址的負載均衡，目前主要用於Cache集羣系統，它與LBLC算法不同之處是它要維護從一個目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。按'最小連接'原則從該服務器組中選出一一臺服務器，若服務器沒有超載，將請求發送到該服務器；若服務器超載，則按'最小連接'原則從整個集羣中選出一臺服務器，將該服務器加入到這個服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低複製的程度。

7.目標地址散列調度

目標地址散列調度（Destination Hashing 簡稱'DH'）算法先根據請求的目標IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且並未超載，將請求發送到該服務器，否則返回空。

8.源地址散列調度U

源地址散列調度（Source Hashing 簡稱'SH'）算法先根據請求的源IP地址，作爲散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且並未超載，將請求發送到該服務器，否則返回空。它採用的散列函數與目標地址散列調度算法的相同，它的算法流程與目標地址散列調度算法的基本相似。

9.最短的期望的延遲

最短的期望的延遲調度（Shortest Expected Delay 簡稱'SED'）算法基於WLC算法。舉個例子吧，ABC三臺服務器的權重分別爲1、2、3 。那麼如果使用WLC算法的話一個新請求進入時它可能會分給ABC中的任意一個。使用SED算法後會進行一個運算

A：（1+1）/1=2 B：（1+2）/2=3/2 C：（1+3）/3=4/3 就把請求交給得出運算結果最小的服務器。

10.最少隊列調度

最少隊列調度（Never Queue 簡稱'NQ'）算法，無需隊列。如果有realserver的連接數等於0就直接分配過去，不需要在進行SED運算。

架構之美【kubernetes、Prometheus、微服務、LVS負載均衡】