直面PHP微服務架構挑戰

在4月20日的阿里雲棲開發者沙龍PHP技術專場上，雲智慧Technical VP高馳濤爲你們介紹了微服務的前世此生，分享了微服務架構實踐中所面對的諸多挑戰以及相應的應對策略。

本次直播視頻精彩回顧，戳這裏！
直播回顧：https://yq.aliyun.com/live/965
PPT分享：https://yq.aliyun.com/download/3527

如下內容根據演講視頻以及PPT整理而成。

專家簡介

高馳濤 (Neeke Gao)，雲智慧Technical VP，PHP/PECL開發組成員，具備10餘年研發管理經驗，同時也是PECL/SeasLog、PECL/JsonNet、GoCrab等多項開源軟件的做者。2014年加入雲智慧，致力於APM與大數據產品的架構研發，崇尚敏捷、高效。

從一個問題談起

首先，從幾年以前某CTO的一個問題談起，這個問題是「咱們的系統將會擁有五千個微服務組件。咱們應該怎麼作？」你們能夠仔細思考這個問題，咱們都知道一個接口確定沒法稱之爲微服務，達到十幾個接口或許纔可以叫作微服務。那麼，對於包含五千個微服務的系統而言，又該怎麼實現和管理呢？其實，這樣的系統背後會存在很大的問題。

本次分享將會主要圍繞如下三個方面內容展開：

1. 微服務的前世此生
2. 微服務的挑戰
3. 應該怎麼面對

微服務的前世此生

下圖所展示的內容其實能夠說是供你們在茶餘飯後聊天的談資，若是想要知道微服務是如何誕生的，那麼就必需要了解如下四個領域的知識。

TOGAF：全稱爲「開放組體系結構框架」，TOGAF在上世紀7、八十年代的時候就已經由專門組織負責開發了，但一直到1995年的時候，美國國防部參與以後，TOGAF才最終成型。舉例而言，你們手機里正在使用的產品和應用中，不少都會用到SAP、IBM或者惠普等的軟件，而這些軟件公司所遵循的就是TOGAF。能夠說目前全球超過50%的企業正在使用TOGAF實踐軟件架構設計和開發。TOGAF是一個架構體系，而並無提供具體的架構方法。TOGAF包含了業務架構、應用架構、數據架構、技術架構等，其實，阿里雲的全局組件也屬於TOGAF中的技術架構領域，其可以幫助客戶減小各類繁雜的思考，使得客戶只須要關注於業務架構便可。
TOGAF有三個最爲主要支柱：
1)企業架構域，主要是企業信息與業務流等；
2）ADM一系列的架構方法論；
3）企業連續性，指的是在企業業務高速增加而且也不斷變動的過程當中，保證架構體系的連續性。

DDD：全稱爲「領域驅動設計」，其包含了諸多的概念，可是你們只須要記住主要的三句話便可。
1）DDD是精簡的業務，DDD首先關注的就是業務，把各類繁瑣的業務流程精簡成更細的鏈條；
2）DDD須要回答業務是幹什麼的，可以知足什麼需求，達成什麼目的；
3）不斷迭代，DDD的不斷迭代與TOGAF的企業連續性相似。

SOA：全稱爲「面向服務架構」，其理論也很是多，可是你們也只須要記住三點。
1）SOA解決了信息孤島的問題，不讓信息變成孤島；
2）業務重用，從業務角度將各個服務組合成一個個中間件或者服務，將其提供給用戶或者其餘系統；
3）SOA使得系統成爲互聯互通的信息羣。

GRASP原則：全稱爲「通用職責分配原則」，其實不少你們耳熟能詳的概念如「低耦合」、「高內聚」都來自於GRASP原則。其與設計模式不一樣，設計模式指導如何實現系統，而GRASP指導如何劃分。GRASP原則指導定義業務架構以及API等相關內容和劃分服務，其理論內容也很是多，可是隻須要記住三個關鍵：
1）本身幹本身的事；
2）本身只幹本身能幹的事；
3）本身只幹本身的事，強調了資源劃分。

在軟件工程的教科書上給出了微服務架構的定義：微服務架構是一種架構模式，它提介將單一應用程序劃分紅一組小的服務，服務之間互相協調、互相配合，爲⽤戶提供最終價值。每一個服務運行在其獨立的進程中，服務與服務間採用輕量級的通訊機制互相溝通(一般是基於HTTP協議的RESTFul API)。每一個服務都圍繞着具體業務進⾏構建，而且可以被獨⽴的部署到⽣產環境、類⽣產環境等。另外，應當儘可能避免統一的、集中式的服務管理機制，對具體的一個服務⽽言，應根據業務上下⽂，選擇合適的語言、工具對其進行構建。而這些教科書上的內容或許在當下來看已通過時了。

微服務帶來的優點

那麼，咱們使用微服務架構的時候，到底獲得了什麼東西呢？其實獲得了不少，這裏爲你們總結了四點最爲明顯的優勢。
1）使得開發和迭代變得更加敏捷，使用微服務架構使得敏捷開發成爲可能；
2）易於擴展和收縮，一些公司基於Kubernetes、Docker等技術能夠在幾秒內拉起上萬個微服務，當大型流量衝擊到達的時候，能夠實現無損地承擔所有流量，同時實現用戶無感知，而當數據訪問量下降以後，又能夠實現快速縮容；
3）多技術棧可能，目前智慧雲的技術棧很是全面，雖然開發人員只有60多人，可是開發語言卻多達10多門，而使用微服務能夠有效地組織各種開發人員；
4）高可修改性，好比實現數據庫的快速遷移，通道的快速切換等。

微服務帶來的兩點疑問

這裏再提出兩個問題，雖然微服務可以帶來諸多優勢，可是也存在兩點疑問。第一個就是「微服務架構，你的系統變得更健壯了嗎？」；第二個則是「使用微服務讓系統變得更快了嗎？」對於這兩點而言，可能說是見仁見智的。有人說由於組件變得愈來愈多，可監控性就會變難，所以系統健壯性就會變得愈來愈差，也有人說由於將系統拆分得愈來愈細，所以健壯性就會愈來愈強。若是單體架構是串行的，那麼使用微服務能夠將其變成並行的和分佈式的，而多個組件之間進行通訊，也會使得通訊成爲性能瓶頸，那麼使用微服務究竟是變快了仍是變慢了呢？這兩個問題都很難以回答。而做爲一個架構師或者開發者須要進行深刻的思考。

微服務架構面臨的挑戰和思考

這裏爲你們總結了在使用微服務架構的時候所須要面臨的8條挑戰和相關的思考。

1. 小便是多

當業務從大變小的時候，也意味着業務變多了。由大變小，可使系統變得更加容易維護和修改，可是由少變多，又會使得問題更加複雜，所以也會有不少的挑戰。第一個問題就是多節點、多服務和多狀態。系統中的節點、組件服務變得更多了，那麼節點和服務之間的狀態也會變得更難維護，更加複雜。基於前面提到的四種知識，其實能夠將從大變小和從少變多這兩個轉變進行折中，使得其變得更加可控。而解決這個問題的關鍵在於對於服務的合理拆分，主要有三點能夠考慮，即數據資源、業務功能以及服務對象。

2. 債務管理

好比Bug、代碼缺陷、未完成的功能或者版本不兼容等問題都是債務。當服務變得愈來愈多的時候，債務每每就會變得更多。爲了解決這些問題，其實有這樣的幾種策略，好比單元測試，若是單元測試作的足夠好，那麼代碼缺陷的可能性就會變得更低一些，能夠將服務由少變多所形成的債務變多狀況進行收斂；集成迴歸，這部分提供了不少工具去作這件事情，不用開發者本身去作；版本管理，這裏指的是靜態庫的版本管理，動態庫指的是正在變動中的庫，而靜態庫指的是再也不變動的庫和配置項，這一點控制很差，就容易使得系統管理混亂；迭代衝刺，這是一種組織方式，當有不少技術債務須要進行管理時，如何將這些債務一點點處理掉或者把發散的趨勢收斂住，迭代衝刺就是一種作法；Bug Crash，這是智慧雲團隊本身發明的一個名詞，至關因而對於Bug的大掃除，不管採用傳統的仍是敏捷的開發模式，都有一些Bug存在，所以按期會組織全體開發和測試以及產品將本身的產品用一遍，進行Bug大掃除；迴歸總結，不管採用什麼開發模式，在一個迭代週期完成以後，迴歸總結是少不了的，也須要經過一些方法解決新發生的問題，或者將其封閉住不使債務繼續蔓延。

3. 複雜的服務依賴

若是隻有一個或者幾個組件，那麼其實不存在服務依賴問題，而若是有幾千個組件，那麼服務依賴將會成爲巨大的問題。舉例而言，若是用戶服務須要調用訂單服務，那麼在啓動的時候須要進行一些初始化任務，那麼一個服務的版本發佈可能致使系統全面癱瘓，這就是複雜服務依賴問題。爲了解決這個問題首先就須要服務發現機制，好比使用etcd或者Zookeeper等，首先服務發現中心也須要是分佈式高可靠的，那麼服務起來以後須要把本身的名字和調用方式告訴服務發現中心，註冊上去，對於服務調用者而言只須要從服務發現中心那裏經過約定好的名字獲取服務調用地址便可。依賴喚醒是有一個相對比較新的東西，好比大流量忽然打進來的時候，A服務須要從原來的10個啓動到100個，而B從原來的3個確定也是不夠用的，所以須要經過喚醒的機制將服務拉起來，而不是被動的被通知。還有一種狀況也須要使用到依賴喚醒機制，好比緩存穿透問題，正常狀況下，緩存是生效的，不會存在穿透的狀況，可是可能由於某種異常使得緩存不生效了，會將大量的流量打到DB裏面去，使得服務變得不可用了，整個服務雪崩掉，針對這些問題通常會開發一些擋板服務，可能會給出一些固定的數據，而這些擋板服務也有可能會面臨這種突發的流量也須要經過依賴喚醒的機制實現喚醒。此外，還有灰度發佈和AB測試，這兩點是相關聯的。還有多版本共存問題，對於服務的多版本也是一個技術債務問題，須要考慮如何將其舊版本拿下來。

4. 消息通信

若是系統中包含多個語言棧，多種實現方式。那麼統一標準是必須的，要麼統一一種RPC或者就使用RestFul API等。消息中心也是一種處理作法，這一點在Java中應用不少，消息中心並非消息隊列，而是一個事件驅動的消息中心。此外，還有通信網關，這在使用微服務的時候也是一個必要點，其主要解決了監控問題，並且能夠經過網關起到中控的做用，好比安全、性能以及用戶校驗等任務。

5. 分佈式事務

在實現分佈式事務的時候能夠採用2PC或者3PC原則來實現，2PC原則是經過所有節點投票和執行兩個步驟完成的，而且是阻塞的；而3PC則不一樣，雖然在一個具體的事務裏面能夠是阻塞的，也能夠是非阻塞的。3PC協議則是經過「Can-Pre-Do」三個步驟來實現的，其實PDU就是3PC協議在單體中的實現方式。而在分佈式系統中，3PC有三種實現方式，使用分佈式的事件驅動、最大通知以及兩階段補償TCC。

6. 花式故障

不少時候，當系統出現問題可能須要花費數週和不少人力才能找到根源所在，可能由於系統太多，使得系統架構師也沒法清楚系統與系統之間的關係。面對諸多的花式故障，也有多種策略能夠應對，好比全鏈路追蹤，好比使用Open Tracking；主動撥測，不少用戶端的APP裏面內置探針，使其能夠接收Server端的指令來按期探測接口和服務是否正常。

7. 中心與去中心

中心與去中心能夠算是一個永恆的話題，上圖中展現的配置、發號、日誌、調度、狀態以及預警，其實對於比較成熟的大型系統而言，這六點都是須要中心的。

8. 組織危機

最後一個問題，也是最大的問題。其實要實現向微服務架構的變動的時候，最大的問題就是組織危機。這一點與開發者關係不大，可是對於Team Leader以及組織的管理人員而言，關係就很是大了。架構的轉變須要考慮到信任危機、過時維護、多語言棧、溝通協做、安全網關以及輪崗結對等問題。

總結

總結而言，最重要的觀點有兩個：微服務不是銀彈。不要讓重複的事情作兩次。

原文連接 本文爲雲棲社區原創內容，未經容許不得轉載。