1.1 互聯(lián)網(wǎng)架構(gòu)變遷

1.1.1 互聯(lián)網(wǎng)架構(gòu)的核心問題

互聯(lián)網(wǎng)應(yīng)用的業(yè)務(wù)特征決定了它和企業(yè)級應(yīng)用具有諸多不同，具體來說，主要有以下幾點(diǎn)。

海量用戶

互聯(lián)網(wǎng)應(yīng)用幾乎無差別地為全世界所有的用戶提供服務(wù)，與服務(wù)于局域網(wǎng)用戶的企業(yè)級應(yīng)用相比，其用戶量要大得多，由海量用戶產(chǎn)生的數(shù)據(jù)量自然也會呈幾何級增長。

與日常生活中的真實(shí)場景不同，在網(wǎng)站用戶量超過應(yīng)用負(fù)荷的閾值之前，互聯(lián)網(wǎng)用戶不會明顯感受到由用戶量增長所導(dǎo)致的服務(wù)質(zhì)量下降。舉一個簡單的例子，當(dāng)我們?nèi)ド虉鲑徫飼r，如果只有10位顧客在場，所感受到的環(huán)境舒適度、所享受的服務(wù)質(zhì)量，以及等待時間，與有100位顧客在場時肯定會有很大的不同。而在網(wǎng)上購物時，有10位用戶同時購買與有100位用戶同時購買，我們幾乎感受不到任何差別。但用戶數(shù)一旦超過了網(wǎng)站應(yīng)用所能夠承載的閾值，比如1000萬人同時購買，那么整個網(wǎng)站在處理不當(dāng)?shù)那闆r下便會完全失去響應(yīng)，如果處理得嚴(yán)重不當(dāng)，還會導(dǎo)致用戶交易數(shù)據(jù)丟失，最壞的情況是部分用戶付款之后卻不能收到商品，且投訴無門、查無對賬。

互聯(lián)網(wǎng)應(yīng)用對于用戶量的預(yù)估遠(yuǎn)遠(yuǎn)沒有企業(yè)級應(yīng)用那么準(zhǔn)確，在業(yè)務(wù)發(fā)展迅速的情況下，用戶量的增長是爆發(fā)性且沒有上限的。

產(chǎn)品迅速迭代

隨著業(yè)務(wù)模式的快速拓展，互聯(lián)網(wǎng)應(yīng)用功能推陳出新的速度也越來越快。在當(dāng)今這個節(jié)奏如此快的時代，時間成本顯得非常關(guān)鍵。敏捷地探知市場需求并將其實(shí)現(xiàn)，是互聯(lián)網(wǎng)行業(yè)的立命之本。產(chǎn)品快速升級必然會推動開發(fā)、測試、交付甚至系統(tǒng)迅速迭代。

7×24小時不間斷服務(wù)

互聯(lián)網(wǎng)應(yīng)用是一個面向全球的服務(wù)應(yīng)用，由于具有時區(qū)差異，因此應(yīng)用必須保證全天隨時可用。

各種意外情況，如光纜挖斷、機(jī)房失火等，都可能對系統(tǒng)的可用性產(chǎn)生影響，每次宕機(jī)都會造成很大的損失。另外，如果系統(tǒng)設(shè)計(jì)得不夠健壯，對其升級和維護(hù)時就要停止服務(wù)。頻繁的系統(tǒng)升級同樣會對系統(tǒng)可用性產(chǎn)生很大的影響，而互聯(lián)網(wǎng)公司每天多次進(jìn)行應(yīng)用上線是很常見的行為，發(fā)布常態(tài)化已漸漸成為互聯(lián)網(wǎng)行業(yè)的標(biāo)準(zhǔn)。

雖然隨時隨處可用的難度非常大，但互聯(lián)網(wǎng)應(yīng)用會盡量縮短宕機(jī)時間。通常使用3～5個9 （3個9即99.9%,4個9即99.99%,5個9即99.999%）作為衡量系統(tǒng)可用性的指標(biāo)，表示系統(tǒng)在1年的運(yùn)行過程中可以正常使用的時間與總運(yùn)行時間的比值，下面分別計(jì)算3個9、4個9、5個9指標(biāo)下的全年宕機(jī)時間，我們來感受一下它們的可靠性差異。

在真實(shí)的運(yùn)營環(huán)境下，系統(tǒng)可用性指標(biāo)每提升1個9都是非常不容易的。

流量突增

不同類型的互聯(lián)網(wǎng)公司有著不同的流量突增場景。比如，電商類公司的流量會在“雙11”這樣的大型促銷活動期間突增幾倍、幾十倍甚至上百倍；社交類公司的流量會在熱點(diǎn)事件爆發(fā)時突增。

流量突增分為可預(yù)期型突增和不可預(yù)期型突增，像促銷活動、有計(jì)劃的熱點(diǎn)事件（如美國總統(tǒng)大選、世界杯總決賽等）等引起的流量突增屬于可預(yù)期的流量突增，可以通過提前擴(kuò)容、預(yù)案演練等方式精心為這些流量突增準(zhǔn)備應(yīng)對方案。而意料之外的熱點(diǎn)事件（如地震）往往事發(fā)突然，系統(tǒng)來不及準(zhǔn)備應(yīng)對措施，因此若系統(tǒng)本身的可用性、彈性等非功能需求十分成熟，便可以在某種程度上應(yīng)對流量突增了。

業(yè)務(wù)組合復(fù)雜

很多互聯(lián)網(wǎng)公司都是跨界巨頭，我們知道，即使不跨界，在單一領(lǐng)域編織一個大規(guī)模的成型業(yè)務(wù)系統(tǒng)也并不簡單。

以電商行業(yè)為例，電商系統(tǒng)在應(yīng)用系統(tǒng)層面大致可劃分為賣場、交易、訂單、倉儲、物流等主流程系統(tǒng)，搜索、推薦、社區(qū)、會員、客服、退換貨等面向用戶的前端系統(tǒng)，商品、價格、庫存、配貨、促銷、供應(yīng)鏈等面向后臺員工的后端系統(tǒng)，以及廣告、商家、支付、清算、財(cái)務(wù)、報(bào)表等面向合作伙伴的輔助系統(tǒng)，每個應(yīng)用系統(tǒng)又會劃分為很多子系統(tǒng)。一個粗略的電商系統(tǒng)業(yè)務(wù)架構(gòu)如圖1-1所示。

由于互聯(lián)網(wǎng)行業(yè)的擴(kuò)張速度勢不可當(dāng)，以及其業(yè)務(wù)特征具有特殊性，因此相應(yīng)的底層支撐技術(shù)面臨的挑戰(zhàn)也越來越大。由規(guī)模擴(kuò)張而衍生的問題包括數(shù)據(jù)海量、響應(yīng)遲緩、穩(wěn)定性差、伸縮性差、系統(tǒng)繁多和開發(fā)困難等，因此針對這些問題，互聯(lián)網(wǎng)的技術(shù)架構(gòu)也在逐漸轉(zhuǎn)變，遵循著從集中式到分布式再到云平臺的方向逐步演進(jìn)。

1.1.2 從集中式架構(gòu)到分布式架構(gòu)

集中式架構(gòu)又稱單體式架構(gòu)，在Web 2.0時代并未興起時，這種架構(gòu)十分流行。進(jìn)入21世紀(jì)以來，基于 Web 應(yīng)用的 B/S（Browser/Server）架構(gòu)逐漸取代了基于桌面應(yīng)用的 C/S （Client/Server）架構(gòu)。B/S架構(gòu)的后端系統(tǒng)大都采用集中式架構(gòu)，它當(dāng)時憑借優(yōu)雅的分層設(shè)計(jì)統(tǒng)一了服務(wù)器后端開發(fā)領(lǐng)域。

傳統(tǒng)的三層架構(gòu)模型

在Web 2.0時代剛剛流行的時候，互聯(lián)網(wǎng)應(yīng)用與企業(yè)級應(yīng)用并沒有本質(zhì)的區(qū)別，集中式架構(gòu)分為標(biāo)準(zhǔn)的三層：數(shù)據(jù)訪問層、服務(wù)層和Web層。傳統(tǒng)的三層架構(gòu)模型如圖1-2所示。

數(shù)據(jù)訪問層用于定義數(shù)據(jù)訪問接口，實(shí)現(xiàn)對真實(shí)數(shù)據(jù)庫的訪問；服務(wù)層用于對應(yīng)用業(yè)務(wù)邏輯進(jìn)行處理；Web層用于處理異常、邏輯跳轉(zhuǎn)控制、頁面渲染模板等，其又被稱為MVC（Model View Controller）層。

這三層之間既可以共享領(lǐng)域模型對象，又可以進(jìn)行更加細(xì)致的拆分。通常的做法是，數(shù)據(jù)訪問層使用實(shí)體對象（Entity），每個實(shí)體對象對應(yīng)數(shù)據(jù)庫中的一條數(shù)據(jù)。實(shí)體對象和值對象（VO）組成領(lǐng)域模型（Domain Model），被服務(wù)層使用。而邏輯控制層由于需要和前端的Web頁面打交道，需要封裝大量的表單，因此使用由領(lǐng)域模型轉(zhuǎn)換的數(shù)據(jù)傳輸對象（DTO）。

服務(wù)層是整個系統(tǒng)的核心，它既直接提供公開的API，也可以通過Web層提供API。服務(wù)層同時可以提供部分私有實(shí)現(xiàn)，用于屏蔽底層實(shí)現(xiàn)細(xì)節(jié)。數(shù)據(jù)訪問層應(yīng)該只由服務(wù)層直接調(diào)用，它無須公開任何公有API。

由于 NoSQL 在傳統(tǒng)三層架構(gòu)模型時代還未興起，因此數(shù)據(jù)訪問層主要是對關(guān)系型數(shù)據(jù)庫進(jìn)行訪問。在Java開發(fā)中，訪問關(guān)系型數(shù)據(jù)庫要通過統(tǒng)一的接口，即JDBC。通過JDBC可以無縫地切換至不同的數(shù)據(jù)庫。常見的關(guān)系型數(shù)據(jù)庫有Oracle、SQL Server、MySQL和DB2等，這些經(jīng)典的關(guān)系型數(shù)據(jù)庫也一直沿用至今。

然而存儲于關(guān)系型數(shù)據(jù)庫的二維關(guān)系表格數(shù)據(jù)與面向?qū)ο蟮挠蚰Ｐ筒⒉蝗菀滓灰挥成?，因此出現(xiàn)了很多ORM（Object-Relationship-Mapping）框架。MyBatis及其前身IBATIS,JPA以及它的默認(rèn)實(shí)現(xiàn)Hibernate，這些都是ORM領(lǐng)域中開源框架的翹楚。JPA是Java官方的持久化層規(guī)范，其完全以面向?qū)ο罄砟钊ゲ僮鲾?shù)據(jù)庫，這種方式雖然設(shè)計(jì)新穎，但實(shí)際用起來卻略顯笨重。因此，很多互聯(lián)網(wǎng)公司都采用了更加輕量、可控性更高的MyBatis作為ORM框架的首選。

服務(wù)層用于編寫應(yīng)用的具體業(yè)務(wù)邏輯，它需要一個使用便捷且可以對數(shù)據(jù)訪問層和Web層承前啟后的框架。

Java官方推薦的EJB 2.X過于笨重，其中大量的XML配置以及煩瑣的部署方式，使得它使用起來非常不便。雖然后來Sun公司又推出了EJB 3.X，在使用上簡化了很多，但依然無法成為Java開發(fā)的標(biāo)準(zhǔn)。

由Rod Johnson這位業(yè)界大神開發(fā)的Spring Framework，極大地簡化了Java EE的開發(fā)，它提供的IOC（控制反轉(zhuǎn)）和AOP（面向切面編程）特性為開發(fā)者提供了便利，并且迅速地成了Java后端開發(fā)的實(shí)際標(biāo)準(zhǔn)。Spring Framework提供了一個容器，容器中的任何對象都以Bean的方式注入，它像膠水一樣優(yōu)雅地粘貼數(shù)據(jù)訪問對象和其他第三方組件，它并不僅僅是一個定位于服務(wù)層的框架，而是一個貫穿于應(yīng)用整個生命周期的生態(tài)圈。

Web層又叫MVC層，它用于分離前端展現(xiàn)和后端服務(wù)。由于Java的標(biāo)準(zhǔn)實(shí)現(xiàn)——Servlet侵入了大量的HttpRequest、HttpResponse、HttpSession等 API，導(dǎo)致基于Servlet開發(fā)的程序并不適合用于單元測試，而且實(shí)現(xiàn)配置、跳轉(zhuǎn)、表單封裝等操作時也需要做大量的重復(fù)工作，因此，很多MVC框架應(yīng)運(yùn)而生，用于改善開發(fā)流程。

常見的MVC框架有Strtus 1.X，以及基于WebWork封裝的Struts 2.X和Spring MVC。初期Struts系列由于使用簡單而備受青睞，后來Spring對MVC投入的力度越來越大，由于其更加清晰的設(shè)計(jì)理念以及強(qiáng)大的與Spring Framework融合的能力，使得它漸漸成為業(yè)界主流。

在這種All in One的集中式架構(gòu)下，每個開發(fā)者都是全棧工程師。由Spring + Struts（Spring MVC）+ Hibernate組成的SSH框架套件，或由Spring + Struts（Spring MVC）+ IBATIS（MyBatis）組成的SSI框架套件，成了技術(shù)選型的主流。當(dāng)時的軟件工程方法論主要關(guān)注質(zhì)量保證和設(shè)計(jì)靈活性，TDD（測試驅(qū)動開發(fā)）和DDD（領(lǐng)域驅(qū)動開發(fā)）也是時常被討論的話題。

分布式架構(gòu)、SOA和服務(wù)化

由于互聯(lián)網(wǎng)應(yīng)用規(guī)模迅速增長，集中式架構(gòu)已無法做到無限制地提升系統(tǒng)的吞吐量，它只能通過增加服務(wù)器的配置有限度地提升系統(tǒng)的處理能力，這種伸縮方式被稱為垂直伸縮。與之相對的伸縮方式被稱為水平伸縮，水平伸縮能夠僅通過增減服務(wù)器數(shù)量相應(yīng)地提升和降低系統(tǒng)的吞吐量。這種分布式系統(tǒng)架構(gòu)，在理論上為吞吐量的提升提供了無限的可能。因此，用于搭建互聯(lián)網(wǎng)應(yīng)用的服務(wù)器也漸漸放棄了昂貴的小型機(jī)，轉(zhuǎn)而采用大量的廉價PC服務(wù)器。

分布式系統(tǒng)的引入，雖然解決了整個應(yīng)用的吞吐量上限問題，但它并不是能夠解決一切問題的“銀色子彈”。分布式系統(tǒng)在帶來便利的同時，也帶來了額外的復(fù)雜度。

分布式場景下比較著名的難題就是 CAP 定理。CAP 定理認(rèn)為，在分布式系統(tǒng)中，系統(tǒng)的一致性（Consistency）、可用性（Availability）、分區(qū)容忍性（Partition tolerance），三者不可能同時兼顧。在分布式系統(tǒng)中，由于網(wǎng)絡(luò)通信的不穩(wěn)定性，分區(qū)容忍性是必須要保證的，因此在設(shè)計(jì)應(yīng)用的時候就需要在一致性和可用性之間權(quán)衡選擇。互聯(lián)網(wǎng)應(yīng)用比企業(yè)級應(yīng)用更加偏向保持可用性，因此通常用最終一致性代替?zhèn)鹘y(tǒng)事務(wù)的ACID強(qiáng)一致性。

隨著分布式系統(tǒng)架構(gòu)的普及，越來越多的互聯(lián)網(wǎng)公司在重新審視一個并不嶄新但卻一直難于落地的概念，那就是SOA。

SOA 即面向服務(wù)架構(gòu)，這是一個特別寬泛的概念，可以簡單地認(rèn)為 SOA 約等于“模塊化開發(fā) + 分布式計(jì)算”。SOA需要從宏觀和微觀兩個不同的角度討論。

宏觀SOA面向高層次的部門級別、公司級別甚至行業(yè)級別，涉及商業(yè)、管理、技術(shù)等方面，設(shè)計(jì)時要全局考慮。SOA是面向宏觀層面的架構(gòu)，其帶來的收益也最能在宏觀層面體現(xiàn)出來，因此很多業(yè)界專家都認(rèn)為SOA的概念過于抽象、不接地氣。

微觀SOA則面向團(tuán)隊(duì)和個人，涉及具體服務(wù)在業(yè)務(wù)、架構(gòu)和開發(fā)方面的實(shí)施，在架構(gòu)體系上包括服務(wù)治理、服務(wù)編排等內(nèi)容。微觀層面的SOA更容易實(shí)施。

由于SOA有相當(dāng)大的實(shí)施難度和相當(dāng)高的學(xué)習(xí)門檻，因此我們不妨先從一個小故事說起，從中“管窺”一點(diǎn)SOA的大意和作用。根據(jù)亞馬遜前著名員工Steve Yegge的著名“酒后吐槽”事件可知，2002年左右，亞馬遜 CEO 貝佐斯就在亞馬遜內(nèi)部強(qiáng)制推行了以下六項(xiàng)原則（摘自酷殼網(wǎng)）。

所有團(tuán)隊(duì)開發(fā)的程序模塊都要通過Service接口將數(shù)據(jù)與功能開放出來。

團(tuán)隊(duì)間程序模塊的信息通信都要通過上述接口。

除上述通信方式外，其他方式一概不允許使用：不能直接連接程序，不能直接讀取其他團(tuán)隊(duì)的數(shù)據(jù)庫，不能使用共享內(nèi)存模式，不能使用他人模塊的內(nèi)部入口等。

任何技術(shù)都可以使用，比如HTTP、Corba、發(fā)布/訂閱、自定義的網(wǎng)絡(luò)協(xié)議等。

所有的Service接口，毫無例外，都必須從骨子里到表面上被設(shè)計(jì)成能對外界開放的。也就是說，團(tuán)隊(duì)必須做好規(guī)劃與設(shè)計(jì)，以便未來把接口開放給全世界的程序員。

不按照以上要求做的人會被炒魷魚。

據(jù)說，亞馬遜網(wǎng)站上展示產(chǎn)品明細(xì)的頁面，可能需要調(diào)用上百個服務(wù)，以便生成高度個性化的內(nèi)容。貝佐斯還提到，亞馬遜的公司文化已經(jīng)轉(zhuǎn)變成“一切以服務(wù)為第一”，公司的系統(tǒng)架構(gòu)都圍繞這一宗旨構(gòu)建。如今，這已經(jīng)成為亞馬遜進(jìn)行所有設(shè)計(jì)的基礎(chǔ)。貝佐斯的六項(xiàng)原則展示出了超強(qiáng)的信念和高遠(yuǎn)的眼光，即使放到十幾年后的今天，依然令人感到醍醐灌頂。

由于分布式系統(tǒng)十分復(fù)雜，因此產(chǎn)生了大量的用于簡化分布式系統(tǒng)開發(fā)的分布式中間件和分布式數(shù)據(jù)庫，服務(wù)化的架構(gòu)設(shè)計(jì)理念也被越來越多的公司所認(rèn)同。

2011年前后，阿里巴巴開源的 Dubbo 框架成為對后世影響深遠(yuǎn)的一款分布式服務(wù)框架。Dubbo 官方文檔公布了一張有關(guān) SOA 系統(tǒng)演化過程的圖片（見圖1-3），徹底奏響了分布式和SOA時代的最強(qiáng)音。服務(wù)發(fā)現(xiàn)、負(fù)載均衡、失效轉(zhuǎn)移、動態(tài)擴(kuò)容、數(shù)據(jù)分片、調(diào)用鏈路監(jiān)控等分布式系統(tǒng)的核心功能也一個個趨于成熟。

自動化運(yùn)維

隨著分布式系統(tǒng)愈加成熟，應(yīng)用的規(guī)模越來越大，系統(tǒng)構(gòu)成也越來越復(fù)雜，服務(wù)器的數(shù)量迅速地從幾十臺、上百臺增加到成千上萬臺。企業(yè)內(nèi)部服務(wù)器數(shù)量的大幅增長，使得服務(wù)器出現(xiàn)故障的頻次也大幅增加，手工運(yùn)維時代的瓶頸隨之到來。

運(yùn)維工程師越來越難以遠(yuǎn)程登錄每一臺服務(wù)器去搭建環(huán)境、部署應(yīng)用、清理磁盤、查看服務(wù)器狀態(tài)以及排查系統(tǒng)錯誤，此時急需自動化運(yùn)維體系與開發(fā)技術(shù)體系配合。自動化運(yùn)維工具主要包括兩大類：監(jiān)控自動化工具以及流程自動化工具。

監(jiān)控自動化工具可以對服務(wù)器的 CPU、內(nèi)存、磁盤 I/O、網(wǎng)絡(luò) I/O 等重要配置進(jìn)行主動探測監(jiān)控，一旦指標(biāo)超過或接近閾值則自動通過郵件、短信等方式通知相關(guān)責(zé)任人。使用Nagios、Zabbix等系統(tǒng)監(jiān)控工具可以有效實(shí)現(xiàn)這一點(diǎn)。

流程自動化工具主要對服務(wù)器進(jìn)行維護(hù)，同時實(shí)現(xiàn)應(yīng)用上線部署等日常操作的自動化和標(biāo)準(zhǔn)化。Puppet、Chef、Ansible、SaltStack 等自動化運(yùn)維管理工具的出現(xiàn)，快速地將運(yùn)維工作推向自動化，讓一名運(yùn)維工程師可以很容易地維護(hù)成千上萬臺服務(wù)器。

解放交付的DevOps

分布式架構(gòu)解決了互聯(lián)網(wǎng)應(yīng)用吞吐量的瓶頸；越來越成熟的分布式中間件也屏蔽了分布式系統(tǒng)的復(fù)雜度，提升了開發(fā)工程師的工作效率；自動化運(yùn)維工具則提升了運(yùn)維工程師的工作效率。但是，由于目標(biāo)不同，在固有的將開發(fā)和運(yùn)維劃分為不同部門的組織結(jié)構(gòu)中，部門之間的配合并不總是很默契的。

開發(fā)部門的驅(qū)動力通常是頻繁交付新特性，而運(yùn)維部門則更關(guān)注服務(wù)的可靠性。兩者目標(biāo)的不匹配使得部門之間產(chǎn)生了鴻溝，從而降低了業(yè)務(wù)交付的速度與價值。

直到DevOps方法論出現(xiàn)，開發(fā)與運(yùn)維之間的鴻溝才得以漸漸消失。DevOps是可以幫助開發(fā)工程師和運(yùn)維工程師在實(shí)現(xiàn)各自目標(biāo)的前提下，向最終用戶交付價值最大化、質(zhì)量最高的成果的一系列基本原則。DevOps在軟件開發(fā)和交付流程中強(qiáng)調(diào)“在產(chǎn)品管理、軟件開發(fā)以及運(yùn)維之間進(jìn)行溝通與協(xié)作”。

DevOps是一種公司文化的變遷，它代表了開發(fā)、運(yùn)維和測試等環(huán)節(jié)之間的協(xié)作，因此多種工具可以組成一個完整的DevOps工具鏈，如圖1-4所示。

1.1.3 從分布式架構(gòu)到云原生架構(gòu)

隨著虛擬化技術(shù)的成熟和分布式架構(gòu)的普及，用來部署、管理和運(yùn)行應(yīng)用的云平臺被越來越多地提及。IaaS、PaaS和SaaS是云計(jì)算的三種基本服務(wù)類型，分別表示關(guān)注硬件基礎(chǔ)設(shè)施的基礎(chǔ)設(shè)施即服務(wù)、關(guān)注軟件和中間件平臺的平臺即服務(wù)，以及關(guān)注業(yè)務(wù)應(yīng)用的軟件即服務(wù)。容器的出現(xiàn)，使原有的基于虛擬機(jī)的云主機(jī)應(yīng)用，徹底轉(zhuǎn)變?yōu)楦屿`活和輕量的“容器+編排調(diào)度”的云平臺應(yīng)用。

新紀(jì)元的分水嶺——容器技術(shù)

在過去幾年里，云平臺發(fā)展迅速，但其中困擾運(yùn)維工程師最多的，是需要為各種迥異的開發(fā)語言安裝相應(yīng)的運(yùn)行時環(huán)境。雖然自動化運(yùn)維工具可以降低環(huán)境搭建的復(fù)雜度，但仍然不能從根本上解決環(huán)境的問題。

Docker的出現(xiàn)成為了軟件開發(fā)行業(yè)新的分水嶺，容器技術(shù)的成熟也標(biāo)志著技術(shù)新紀(jì)元的開啟。Docker提供了讓開發(fā)工程師可以將應(yīng)用和依賴封裝到一個可移植的容器中的能力，這項(xiàng)舉措使得Docker大有席卷整個軟件行業(yè)并且進(jìn)而改變行業(yè)游戲規(guī)則的趨勢，這像極了當(dāng)年智能手機(jī)剛出現(xiàn)時的場景——改變了整個手機(jī)行業(yè)的游戲規(guī)則。Docker通過集裝箱式的封裝方式，讓開發(fā)工程師和運(yùn)維工程師都能夠以Docker所提供的“鏡像+分發(fā)”的標(biāo)準(zhǔn)化方式發(fā)布應(yīng)用，使得異構(gòu)語言不再是捆綁團(tuán)隊(duì)的枷鎖。

新紀(jì)元的編排與調(diào)度系統(tǒng)

容器單元越來越散落使得管理成本逐漸上升，大家對容器編排工具的需求前所未有的強(qiáng)烈， Kubernetes、Mesos、Swarm等為云原生應(yīng)用提供了強(qiáng)有力的編排和調(diào)度能力，它們是云平臺上的分布式操作系統(tǒng)。

Kubernetes 是目前世界范圍內(nèi)關(guān)注度最高的開源項(xiàng)目，它是一個出色的容器編排系統(tǒng)，用于提供一站式服務(wù)。Kubernetes 出身于互聯(lián)網(wǎng)行業(yè)巨頭——Google，它借鑒了由上百位工程師花費(fèi)十多年時間打造的Borg系統(tǒng)的理念，安裝極其簡易，網(wǎng)絡(luò)層對接方式十分靈活。

Mesos則更善于構(gòu)建一個可靠的平臺，用來運(yùn)行多任務(wù)關(guān)鍵工作負(fù)載，包括Docker容器、遺留應(yīng)用程序（如Java）和分布式數(shù)據(jù)服務(wù)（如Spark、Kafka、Cassandra、Elastic）。Mesos采用兩級調(diào)度的架構(gòu)，開發(fā)人員可以很方便地結(jié)合公司的業(yè)務(wù)場景定制Mesos Framework。

其實(shí)無論是Kubernetes還是Mesos，它們都不是專門為了容器而開發(fā)的。Mesos早于Docker出現(xiàn)，而Kubernetes的前身Borg更是早已出現(xiàn)，它們都是基于解除資源與應(yīng)用程序本身的耦合限制而開發(fā)的。運(yùn)行于容器中的應(yīng)用，其輕量級的特性恰好能夠與編排調(diào)度系統(tǒng)完美結(jié)合。

唯一為了Docker而生的編排系統(tǒng)是Swarm，它由Docker所在的Moby公司出品，用于編排基于Docker的容器實(shí)例。不同于Kubernetes和Mesos,Swarm是面向Docker容器的，相較于Kubernetes面向云原生PaaS平臺，以及Mesos面向“大數(shù)據(jù)+編排調(diào)度”平臺，Swarm顯得功能單一。在容器技術(shù)本身已不是重點(diǎn)的今天，編排能力和生態(tài)規(guī)劃均略遜一籌的Swarm已經(jīng)跟不上前兩者的腳步。

Kubernetes和Mesos的出色表現(xiàn)給行業(yè)中各類工程師的工作模式帶來了顛覆性的改變。他們再也不用像照顧寵物那樣精心地“照顧”每一臺服務(wù)器，當(dāng)服務(wù)器出現(xiàn)問題時，只要將其換掉即可。業(yè)務(wù)開發(fā)工程師不必再過分關(guān)注非功能需求，只需專注自己的業(yè)務(wù)領(lǐng)域即可。而中間件開發(fā)工程師則需要開發(fā)出健壯的云原生中間件，用來連接業(yè)務(wù)應(yīng)用與云平臺。

架構(gòu)設(shè)計(jì)的變革——微服務(wù)

單體應(yīng)用雖然簡單且深入人心，但是隨著越來越多的應(yīng)用被部署到云端，它的劣勢也體現(xiàn)得愈加明顯。因?yàn)閼?yīng)用變更的范圍和周期被捆綁在一起，因此即使只變更應(yīng)用的一部分，也需要重新構(gòu)建并部署整個單體應(yīng)用，而且擴(kuò)展時無法只對需要更多資源的部分模塊進(jìn)行單獨(dú)擴(kuò)展，必須將應(yīng)用整體擴(kuò)展。這種粗粒度的劃分，不利于對系統(tǒng)進(jìn)行管理，也不利于資源的充分利用。因此，人們越來越傾向于將應(yīng)用進(jìn)行合理的拆分。

在過去的幾年中，微服務(wù)已經(jīng)迅速成為了技術(shù)圈最熱門的術(shù)語之一，微服務(wù)是一種架構(gòu)風(fēng)格，它將一個復(fù)雜的單體應(yīng)用分解成多個獨(dú)立部署的微型服務(wù)，每個服務(wù)運(yùn)行在自己的進(jìn)程中，服務(wù)間的通信采用輕量級通信機(jī)制，如 RESTful API。服務(wù)可以使用不同的開發(fā)語言和數(shù)據(jù)存儲技術(shù)。通過服務(wù)拆分，系統(tǒng)可以更加自由地將資源分配到所需的應(yīng)用中，而無須直接擴(kuò)展整個應(yīng)用。圖1-5直觀地展現(xiàn)了單體應(yīng)用與微服務(wù)的區(qū)別。

采用微服務(wù)架構(gòu)風(fēng)格的團(tuán)隊(duì)將圍繞業(yè)務(wù)組織團(tuán)隊(duì)，而不是圍繞技術(shù)組織團(tuán)隊(duì)，這一點(diǎn)和DevOps有異曲同工之妙。實(shí)施微服務(wù)前的組織結(jié)構(gòu)如圖1-6所示，對于集中式架構(gòu)而言，拆分大型應(yīng)用通常需要在技術(shù)層面上設(shè)立UI團(tuán)隊(duì)、后端開發(fā)團(tuán)隊(duì)、數(shù)據(jù)庫團(tuán)隊(duì)。在這種團(tuán)隊(duì)劃分方式下，即使進(jìn)行簡單更改也會導(dǎo)致協(xié)作團(tuán)隊(duì)垮掉。

微服務(wù)架構(gòu)風(fēng)格則采用圍繞業(yè)務(wù)線進(jìn)行劃分的方式，以保證一個團(tuán)隊(duì)中能擁有UI工程師、開發(fā)工程師、DBA和項(xiàng)目經(jīng)理。實(shí)施微服務(wù)后的組織結(jié)構(gòu)如圖1-7所示。

微服務(wù)的優(yōu)勢是通過清晰的模塊邊界構(gòu)建易于理解的架構(gòu)風(fēng)格，它可以讓每個服務(wù)具有獨(dú)立部署、與開發(fā)語言無關(guān)的能力。分布式系統(tǒng)的開發(fā)成本和運(yùn)維開銷則是伴隨微服務(wù)的普及而需要付出的代價。

相比于集中式架構(gòu)，微服務(wù)架構(gòu)需要額外處理的分布式開發(fā)和運(yùn)維工作包括以下幾點(diǎn)。

配置管理。相比于集中式架構(gòu)的屬性文件配置方式，微服務(wù)架構(gòu)更加傾向于使用集中化的配置中心來存儲配置數(shù)據(jù)。配置中心不一定在任何時候都是100%高可用的，大部分時間，配置是從客戶端的緩存中讀取的，如果配置中心恰好在配置修改時不可用，就會帶來很大的影響，導(dǎo)致配置修改無法及時生效。配置修改要想及時生效，配置中心必須有推送配置變更事件的能力。如果配置中心是高可用的，也要慎重考慮如何保證多個配置中心間的數(shù)據(jù)一致性。

服務(wù)發(fā)現(xiàn)。單體應(yīng)用的服務(wù)是可數(shù)且可人工運(yùn)維的，而對于基于微服務(wù)架構(gòu)的應(yīng)用而言，其服務(wù)數(shù)非常多，數(shù)不勝數(shù)。因此，微服務(wù)框架要具有服務(wù)發(fā)現(xiàn)的能力。一般情況下，服務(wù)發(fā)現(xiàn)是通過向注冊中心注冊服務(wù)實(shí)例的運(yùn)行時標(biāo)識以及對其進(jìn)行監(jiān)聽并反向通知其狀態(tài)變化來實(shí)現(xiàn)的。

負(fù)載均衡。與服務(wù)發(fā)現(xiàn)類似，大量的微服務(wù)應(yīng)用實(shí)例無法通過靜態(tài)修改負(fù)載均衡器的方式進(jìn)行運(yùn)維，因此需要反向代理或使用客戶端負(fù)載均衡器配合服務(wù)發(fā)現(xiàn)動態(tài)調(diào)整負(fù)載均衡策略。

彈性擴(kuò)縮容。這是集中式架構(gòu)所不具備的能力，即能夠在流量洪峰期通過增加應(yīng)用實(shí)例的水平伸縮來增強(qiáng)服務(wù)的處理能力，并且能夠在流量回歸正常時簡單地關(guān)閉應(yīng)用實(shí)例，平滑地將多余的資源移出集群。

分布式調(diào)用追蹤。大量微服務(wù)應(yīng)用的調(diào)用和交互，需要依靠一套完善的調(diào)用鏈追蹤系統(tǒng)來實(shí)現(xiàn)，包括確定服務(wù)當(dāng)前的運(yùn)行狀況，以及在出現(xiàn)狀況時迅速定位相應(yīng)的問題點(diǎn)。

日志中心。在微服務(wù)架構(gòu)中，散落在應(yīng)用節(jié)點(diǎn)上的日志不易排查，而且隨著應(yīng)用實(shí)例的銷毀，日志也會丟失，因此需要將日志發(fā)送至日志中心統(tǒng)一進(jìn)行存儲和排查。

自愈能力。這是一個進(jìn)階功能，如果微服務(wù)應(yīng)用可以通過健康檢查感知各個服務(wù)實(shí)例的存活狀態(tài)，并通過系統(tǒng)資源監(jiān)控以及SLA分析獲知應(yīng)用當(dāng)前的承載量，同時應(yīng)用本身具有彈性擴(kuò)縮容能力且微服務(wù)管控系統(tǒng)具有自動服務(wù)發(fā)現(xiàn)以及調(diào)整負(fù)載均衡的能力，那么便可以根據(jù)合理的調(diào)度策略配置通過調(diào)度系統(tǒng)來自動增加、關(guān)閉和重啟應(yīng)用實(shí)例，達(dá)到系統(tǒng)自愈的效果，使系統(tǒng)更加健壯。

在容器技術(shù)開源社區(qū)、編排系統(tǒng)開源社區(qū)的推動，以及微服務(wù)等開發(fā)理念的帶動下，將應(yīng)用部署到云端已經(jīng)是不可逆轉(zhuǎn)的趨勢。隨著云化技術(shù)的不斷發(fā)展，云原生的概念也應(yīng)運(yùn)而生。在現(xiàn)有業(yè)務(wù)代碼不變的情況下，要想讓分布式系統(tǒng)無縫入云，需要改變的就是中間件。因此，從分布式中間件向云原生中間件變遷，便是本書的重點(diǎn)。