一 PaaS服務(wù)的本質(zhì)

image.png

1. 服務(wù)化是PaaS的本質(zhì)。軟件模塊重用，運行環(huán)境和資源的重用，使用通用的軟件模塊或服務(wù)，通用的軟件通訊協(xié)議，統(tǒng)一的開發(fā)和運維管理方法，最大程度的提高復(fù)用度

2. 分布式是PaaS的根本特性。多租戶隔離、高可用、服務(wù)編排是PaaS的根本特性。

3. 自動化是PaaS的靈魂。自動化部署安裝運維，自動化伸縮調(diào)度是PaaS的關(guān)鍵

二 PaaS平臺整體架構(gòu)圖

image.png

1 最底層的Docker+Kubernetes，提供了
1). 使用Docker對應(yīng)用程序包裝(package)、實例化(instantiate)、運行(run)。
2). 以集群的方式運行、管理跨機器的容器。
3). 解決Docker跨機器容器之間的通訊問題。
4). Kubernetes的自我修復(fù)機制使得容器集群總是運行在用戶期望的狀態(tài)。

2 PaaS調(diào)度層(spring cloud)，又稱為iPass。包括服務(wù)的生命周期管理，服務(wù)監(jiān)控，服務(wù)彈性伸縮，服務(wù)編排等。

3 PaaS服務(wù)能力層，又稱之為aPass。包括中間件服務(wù)：緩存、隊列、作業(yè)系統(tǒng)；數(shù)據(jù)服務(wù)：報表、AI；業(yè)務(wù)服務(wù)：二維碼、用戶、支付等等

4 PaaS的流量調(diào)度。包括流控、路由、降級、灰度、聚合、串聯(lián)以及對高并發(fā)的管理。

5 PaaS的運營管理。認(rèn)證和開放平臺，軟件資源庫，軟件接入等。

6 PaaS的運維管理。主要是DevOps等。

三 PaaS關(guān)鍵技術(shù)

1). 全棧監(jiān)控
2). 服務(wù)調(diào)度
3). 流量與數(shù)據(jù)調(diào)度

3.1 全棧監(jiān)控

一個好的監(jiān)控為了兩個場景而設(shè)計

體檢

容量管理
提供一個全局的系統(tǒng)運行時數(shù)據(jù)展示，可以讓其它工程師知道是否需要加機器或資源

性能管理
可以通過查看大盤，找到系統(tǒng)瓶頸，并能有針對性的優(yōu)化

急診

定位問題
快速的暴露并找到問題的發(fā)生點，幫助技術(shù)人員診斷問題

性能分析
當(dāng)出現(xiàn)非預(yù)期流量提升時，快速找到系統(tǒng)節(jié)點

其架構(gòu)可以用下圖表示

多層體系監(jiān)控架構(gòu)圖

image.png

包括三層
1）基礎(chǔ)層：監(jiān)控主機和底層資源。比如cpu、內(nèi)存、網(wǎng)絡(luò)吞吐、硬盤I/O、硬盤使用等
2）中間層: 包括nginx、Redis、MQ、MySQL、Tomcat等
3）應(yīng)用層：HTTP訪問的吞吐量、響應(yīng)時間、返回碼、調(diào)用鏈路分析、性能瓶頸，還包括用戶端的監(jiān)控等
此外，有了這些監(jiān)控后，需要將數(shù)據(jù)能落實到日志系統(tǒng)，需要
1）日志數(shù)據(jù)格式化
2）監(jiān)控數(shù)據(jù)格式標(biāo)準(zhǔn)化
3）統(tǒng)一的監(jiān)控平臺
4）統(tǒng)一的日志分析

一個好的監(jiān)控系統(tǒng)技術(shù)要點

1. 服務(wù)鏈路跟蹤。從對外的API開始，到對應(yīng)的服務(wù)器，最好到落地的數(shù)據(jù)庫，包括所有的中間件，比如緩存、消息等。開源項目Zipkin實現(xiàn)了鏈路跟蹤功能，此外Java類的服務(wù)還可以用字節(jié)碼技術(shù)做到代碼無侵入式。如下圖所示

   
   
   image.png

2. 服務(wù)調(diào)用時長分布。同樣的，用Zipkin就可以做到

   
   
   image.png

3. 服務(wù)TOP N視圖，包含三種排名方法：a）按調(diào)用量排名 b) 按請求最耗時排名 c）按熱點排名

image.png

4. 數(shù)據(jù)庫操作關(guān)聯(lián)。我們可以很方便的通過JavaAgent字節(jié)碼注入技術(shù)拿到JDBC執(zhí)行數(shù)據(jù)庫操作的執(zhí)行時間

image.png

5. 服務(wù)資源跟蹤。我們服務(wù)可能運行在物理機上，也可能在虛擬機里，還可能是Docker容器中，而我們需要把這些資源關(guān)聯(lián)起來(CPU,MEM,I/O,DISK,NETWORK)

而一旦有了上述數(shù)據(jù)我們就可以達(dá)到如下目標(biāo)。

1. 一臺服務(wù)器掛掉是因為CPU或I/O過高的時候，我們馬上可以知道其會影響到哪些對外服務(wù)的API
2. 當(dāng)一個服務(wù)過慢的時候，我們馬上能看出其是否在做Java GC，或是其所在的節(jié)點是否有資源不足的情況
3. 當(dāng)發(fā)現(xiàn)一個SQL過慢的時候，我們立馬知道其影響的是哪個API
4. 當(dāng)發(fā)現(xiàn)一個消息隊列擁堵時，我們立馬能知道會影響哪些對外服務(wù)的API
   我們可以用一個圖來表示

image.png

3.2 服務(wù)調(diào)度（服務(wù)治理）

這里的服務(wù)調(diào)度就是指除開流量調(diào)度外的服務(wù)治理。主要有以下幾點。

1. 服務(wù)關(guān)鍵程度
2. 服務(wù)依賴關(guān)系
3. 服務(wù)發(fā)現(xiàn)
4. 架構(gòu)版本管理
5. 服務(wù)應(yīng)用聲明周期全管理

服務(wù)關(guān)鍵程度和服務(wù)依賴關(guān)系程度

服務(wù)關(guān)鍵程度要通過對業(yè)務(wù)的梳理來發(fā)現(xiàn)。服務(wù)依賴關(guān)系用Spring Cloud的一套方法就能夠非常好的解決，但是千萬不要出現(xiàn)循環(huán)依賴，解決方式是通過第三方的消息隊列來解耦，此外還有Zipkin這個服務(wù)跟蹤工具來展示這張地圖。

服務(wù)狀態(tài)和服務(wù)生命周期管理

我們需要一個統(tǒng)一的服務(wù)注冊中心，來做到

1. 整個架構(gòu)中有多少種服務(wù)？
2. 這些服務(wù)的版本是怎么樣的？
3. 每個服務(wù)的實例數(shù)有多少個？它們的狀態(tài)是怎么樣的？
4. 每個服務(wù)的狀態(tài)是怎么樣的？是在部署中、運行中、升級中、還是在回滾，伸縮中，或是在下線中
   有了這些狀態(tài)，就能對生命周期進行管理了，主要有以下幾個狀態(tài)
5. Provision，代表在供應(yīng)一個新的服務(wù)
6. Ready, 表示啟動成功了
7. Run, 表示通過了服務(wù)健康檢查
8. Update，表示正在升級中
9. Rollback，表示正在回滾中
10. Scale，表示正在伸縮中
11. Destroy, 表示正在銷毀中
12. Failed，表示失敗的狀態(tài)

有了生命周期的管理，一個紛亂無比的世界就可以干干凈凈的管理起來了

架構(gòu)版本管理

除了各個項目的版本管理外，還需要在上面再覆蓋一層版本管理。比如A服務(wù)的1.2版本只能和B服務(wù)的2.2版本一起工作，如果架構(gòu)中存在不兼容的情況，可以把整個架構(gòu)回滾掉。所以，就需要一個架構(gòu)清單，包括但不限于

1. 服務(wù)的軟件版本
2. 服務(wù)的運行環(huán)境--環(huán)境變量、CPU、內(nèi)存、可運行的結(jié)點、文件系統(tǒng)等
3. 服務(wù)運行的最大和最小實例數(shù)
   而每一次對這個清單的變更都需要記錄下來，算是一個架構(gòu)版本管理。而我們這個集群控制系統(tǒng)需要解讀并執(zhí)行這個清單中的變更，以操作和管理整個集群中的相關(guān)變更。

資源/服務(wù)調(diào)度

服務(wù)和資源調(diào)度有點類似操作系統(tǒng)。操作系統(tǒng)一方面把用戶進程在硬件資源上進行調(diào)度，另一方面提供進程間通信方式，可以讓不同進程在一起協(xié)同工作。
而服務(wù)調(diào)度有以下一些關(guān)鍵技術(shù)。

1. 服務(wù)狀態(tài)的維持和擬合
2. 服務(wù)的彈性伸縮和故障遷移。
3. 作業(yè)的應(yīng)用調(diào)度。
4. 作業(yè)的工作流編排。
5. 服務(wù)編排。

服務(wù)狀態(tài)的維持和擬合

服務(wù)狀態(tài)包括上述服務(wù)生命周期中的狀態(tài)- Provision, Ready,Run, Scale, Rollback, Update, Destory, Failed...而服務(wù)狀態(tài)的變化包括預(yù)期和不預(yù)期的變化

1. 一種是不預(yù)期的變化。比如，如果有服務(wù)掛掉了，或是什么原因服務(wù)不健康的狀態(tài)。如果是一個好的集群管理，應(yīng)該能摘除不健康的服務(wù)，同時又啟動新的服務(wù)，強行維護健康服務(wù)的實例數(shù)。
2. 另一種是預(yù)期的變化。比如需要發(fā)布新版本，需要伸縮，回滾。集群管理控制器就因該把集群從現(xiàn)有狀態(tài)遷移到新的狀態(tài)。這個過程叫“擬合”，舉個栗子，我們需要對集群做Scale的時候，需要
   a) 先擴展幾個節(jié)點
   b) 再往上部署服務(wù)
   c) 然后啟動服務(wù)
   d) 再檢查服務(wù)的健康情況
   e) 最后把擴展出來的服務(wù)實例加入服務(wù)發(fā)現(xiàn)中提供服務(wù)
   這個過程會比較“慢”，一方面，需要對其它操作排它；另一方面，整個過程必須努力逼近最終狀態(tài)。此外，正在運行的服務(wù)也有可能出現(xiàn)問題，離開了我們想要的狀態(tài)，而控制系統(tǒng)檢測到后，會強行維持服務(wù)狀態(tài)。
   Kubernetes就是干這個的，沒有這種控制系統(tǒng)的都不能稱之為PaaS。

服務(wù)的彈性伸縮和故障遷移

有了服務(wù)狀態(tài)擬合的基礎(chǔ)工作后，我們就可以很容易的管理服務(wù)的聲明周期了，具體到彈性伸縮，包括下列步驟：

1. 底層資源的伸縮；
2. 服務(wù)的自動化部署；
3. 服務(wù)的健康檢測
4. 服務(wù)的發(fā)現(xiàn)和注冊
5. 服務(wù)的流量調(diào)度

而對于故障遷移，我們需要自動地恢復(fù)它，對于服務(wù)來說，有兩種模式，一種是寵物模式，一種是奶牛模式

1. 所謂寵物模式，就是一定要救活，對應(yīng)有狀態(tài)的服務(wù)。比如消息服務(wù)，redis緩存等
2. 而奶牛模式，就是不救活了，重新生成一個。

對于這兩種模式，會涉及到

1. 服務(wù)的健康監(jiān)控（APM）
2. 如果寵物模式。需要服務(wù)的重新啟動和服務(wù)的監(jiān)控報警(如果重試不成功就需要人工介入)
3. 如果是奶牛模式。需要服務(wù)的資源申請，服務(wù)的自動化部署，服務(wù)發(fā)現(xiàn)的注冊，以及服務(wù)的流量調(diào)度。

很幸運的是Kubernetes和Docker都幫我們做掉了，只需要把傳統(tǒng)的服務(wù)遷移上來，雖然這可能是一個艱巨的任務(wù)。

服務(wù)工作流和編排

一個好的操作系統(tǒng)需要能夠通過一定的機制把一堆獨立工作的進程給協(xié)同起來。在分布式服務(wù)調(diào)度中，這個工作就叫做"Orchestration"，國內(nèi)叫做"編排"

傳統(tǒng)的SOA架構(gòu)是通過ESB來完成的，其主要功能是通信路由、協(xié)議轉(zhuǎn)換、服務(wù)編制和業(yè)務(wù)規(guī)則應(yīng)用等。

而編排的意思是一個服務(wù)像樂隊指揮一樣，告訴大家該怎么交互。在微服務(wù)中，這需要一個API Gateway或一個簡單的消息隊列來做編排的工作，在Spring Cloud中，所有的請求都是通過Zuul網(wǎng)關(guān)來訪問內(nèi)部服務(wù)，這個和Kubernetes中的Ingress類似。