溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務(wù)條款》
您好，登錄后才能下訂單哦！
本部分節(jié)選自《軟件架構(gòu)設(shè)計》
軟件開發(fā)就是把一個復(fù)雜的問題分解為一系列簡單的問題，再把一系列簡單的解決方案組合成一個復(fù)雜的解決方案。而軟件開發(fā)中最大的挑戰(zhàn)，就是即能夠快速高效地針對需求、環(huán)境的變化做出改變，也能夠持續(xù)提供穩(wěn)定、高可用的服務(wù)。而軟件架構(gòu)，就是軟件系統(tǒng)的骨骼與框架。
所謂架構(gòu)，見仁見智，很難有一個明確或標(biāo)準(zhǔn)的定義；但架構(gòu)并非鏡花水月或陽春白雪，有系統(tǒng)的地方就需要架構(gòu)，大到航空飛機，小到一個電商系統(tǒng)里面的一個功能組件，都需要設(shè)計和架構(gòu)。抽象而言，架構(gòu)就是對系統(tǒng)中的實體以及實體之間的關(guān)系所進行的抽象描述，是對物/信息的功能與形式元素之間的對應(yīng)情況所做的分配，是對元素之間的關(guān)系以及元素同周邊環(huán)境之間的關(guān)系所做的定義。架構(gòu)能將目標(biāo)系統(tǒng)按某個原則進行切分，切分的原則，是要便于不同的角色進行并行工作，結(jié)構(gòu)良好的創(chuàng)造活動要優(yōu)于毫無結(jié)構(gòu)的創(chuàng)造活動。
軟件架構(gòu)的核心價值，即是控制系統(tǒng)的復(fù)雜性，將核心業(yè)務(wù)邏輯和技術(shù)細(xì)節(jié)的分離與解耦。軟件架構(gòu)是系統(tǒng)的草圖，它描述的對象是直接構(gòu)成系統(tǒng)的抽象組件；各個組件之間的連接則明確和相對細(xì)致地描述組件之間的通信。在實現(xiàn)階段，這些抽象組件被細(xì)化為實際的組件，比如具體某個類或者對象。在面向?qū)ο箢I(lǐng)域中，組件之間的連接通常用接口來實現(xiàn)。架構(gòu)師的職責(zé)是努力訓(xùn)練自己的思維，用它去理解復(fù)雜的系統(tǒng)，通過合理的分解和抽象，理解并解析需求，創(chuàng)建有用的模型，確認(rèn)、細(xì)化并擴展模型，管理架構(gòu)；能夠進行系統(tǒng)分解形成整體架構(gòu)，能夠正確的技術(shù)選型，能夠制定技術(shù)規(guī)格說明并有效推動實施落地。
在筆者的知識體系中，實際上將架構(gòu)分為業(yè)務(wù)架構(gòu)、應(yīng)用架構(gòu)、云基礎(chǔ)架構(gòu)這幾大類，業(yè)務(wù)架構(gòu)主要著眼于控制業(yè)務(wù)的復(fù)雜性，基礎(chǔ)架構(gòu)著眼于解決分布式系統(tǒng)中存在的一系列問題。無論何種架構(gòu)，都希望能實現(xiàn)系統(tǒng)的可變的同時保障業(yè)務(wù)的高可用。另一個層面，根據(jù)企業(yè)中職責(zé)的劃分，我們往往可以將軟件架構(gòu)，及關(guān)聯(lián)的架構(gòu)師劃分為以下幾類：
業(yè)務(wù)架構(gòu)/解決方案架構(gòu)：核心是解決業(yè)務(wù)帶來的系統(tǒng)復(fù)雜性，了解客戶/業(yè)務(wù)方的痛點，項目定義，現(xiàn)有環(huán)境；梳理高階需求和非功能性需求，進行問題域劃分與領(lǐng)域建模等工作；溝通，方案建議，多次迭代，交付總體架構(gòu)。
應(yīng)用架構(gòu)：根據(jù)業(yè)務(wù)場景的需要，設(shè)計應(yīng)用的層次結(jié)構(gòu)，制定應(yīng)用規(guī)范、定義接口和數(shù)據(jù)交互協(xié)議等。并盡量將應(yīng)用的復(fù)雜度控制在一個可以接受的水平，從而在快速的支撐業(yè)務(wù)發(fā)展的同時，在保證系統(tǒng)的可用性和可維護性的同時，確保應(yīng)用滿足非功能屬性要求（性能、安全、穩(wěn)定性等）。
數(shù)據(jù)架構(gòu)：專注于構(gòu)建數(shù)據(jù)中臺，統(tǒng)一數(shù)據(jù)定義規(guī)范，標(biāo)準(zhǔn)化數(shù)據(jù)表達(dá)，形成有效易維護的數(shù)據(jù)資產(chǎn)。打造統(tǒng)一的大數(shù)據(jù)處理平臺，包括數(shù)據(jù)可視化運營平臺、數(shù)據(jù)共享平臺、數(shù)據(jù)權(quán)限管理平臺等。
中間件架構(gòu)：專注于中間件系統(tǒng)的構(gòu)建，需要解決服務(wù)器負(fù)載，分布式服務(wù)的注冊和發(fā)現(xiàn)，消息系統(tǒng)，緩存系統(tǒng)，分布式數(shù)據(jù)庫等問題，同時架構(gòu)師要在 CAP 之間進行權(quán)衡。
運維架構(gòu)：負(fù)責(zé)運維系統(tǒng)的規(guī)劃、選型、部署上線，建立規(guī)范化的運維體系。
軟件架構(gòu)設(shè)計的一個核心問題是能否使用重復(fù)的架構(gòu)模式，即能否達(dá)到架構(gòu)級的軟件重用。也就是說，能否在不同的軟件系統(tǒng)中，使用同一架構(gòu)。當(dāng)我們討論軟件架構(gòu)時，常常會提及軟件架構(gòu)模式（Architectural Pattern）與軟件架構(gòu)風(fēng)格（Architectural Style）。
軟件架構(gòu)模式往往會用于具體地解決某個具體的重復(fù)的架構(gòu)問題，而架構(gòu)風(fēng)格則是對于某個具體的架構(gòu)設(shè)計方案的命名。軟件架構(gòu)風(fēng)格是描述某一特定應(yīng)用領(lǐng)域中系統(tǒng)組織方式的慣用模式；架構(gòu)風(fēng)格反映了領(lǐng)域中眾多系統(tǒng)所共有的結(jié)構(gòu)和語義特性，并指導(dǎo)如何將各個模塊和子系統(tǒng)有效組織成一個完整的系統(tǒng)。
在筆者的系列文章中，CRUD、分層架構(gòu)、六邊形架構(gòu)、洋蔥架構(gòu)、REST 以及 DDD，都算是架構(gòu)風(fēng)格；而 CQRS、EDA、UDLA、微服務(wù)等則被劃分到架構(gòu)模式中。
在軟件開發(fā)中，程序員往往能夠脫離現(xiàn)實規(guī)律的束縛，創(chuàng)造出天馬行空的世界，其也是最具有創(chuàng)造力的活動之一。編程唯一需要的是創(chuàng)造力思維和思維組織能力，這意味著在軟件開發(fā)過程中最大限制是理解我們正在創(chuàng)建的對象。隨著軟件的演進，加入更多的功能點，系統(tǒng)變得越來越復(fù)雜：各個模塊（Module）間存在著各種微妙的依賴關(guān)系。系統(tǒng)的復(fù)雜性隨著時間積累，對于程序員來說，修改系統(tǒng)時考慮周全所有的的相關(guān)因素變得越來越困難。這就會使軟件開放進度變緩慢，并且引入 Bug，而導(dǎo)致會進一步延緩開發(fā)進度，增加開發(fā)成本。在任何一個系統(tǒng)的生命周期中，復(fù)雜性不可避免會增加；系統(tǒng)越大，需要更多的人開發(fā)，管理系統(tǒng)復(fù)雜性的工作就越困難。
Eric Evans 在 Domain‐Driven Design 一書中吐槽了所謂的意大利面式架構(gòu)，即代碼確實做了有用的事，但很難解釋它是如何去執(zhí)行的；他認(rèn)為造成這種窘境的主要原因是，將領(lǐng)域問題的復(fù)雜度與技術(shù)細(xì)節(jié)的復(fù)雜度混合在了一起，最終導(dǎo)致整體復(fù)雜度的指數(shù)級增長。
復(fù)雜性不是憑空而來，很多時候也不是刻意為之，這也就意味著復(fù)雜性的增加往往不會以我們的主觀意志為轉(zhuǎn)移。就像房間里的大象，我們無法逃避，也不能視而不見。復(fù)雜性的來源可能是：
吸積與持續(xù)迭代：增量式設(shè)計意味著軟件設(shè)計永不結(jié)束，設(shè)計在系統(tǒng)的生命周期中持續(xù)發(fā)生，程序員要時刻考慮設(shè)計問題。增量開發(fā)也意味著持續(xù)重構(gòu)。一個系統(tǒng)的初始設(shè)計幾乎從來都不是最好的方案。隨著經(jīng)驗的增加，必然會發(fā)現(xiàn)更好的設(shè)計方案。
交互且無擴展性設(shè)計：當(dāng)吸積效應(yīng)導(dǎo)致的大規(guī)模系統(tǒng)，結(jié)合了交互這個特性，會使技術(shù)系統(tǒng)更加復(fù)雜。一個技術(shù)系統(tǒng)除了作用于自身，還會與其它大量系統(tǒng)產(chǎn)生交互。比如下單購買一件商品，那么訂單系統(tǒng)，商品系統(tǒng)，支付系統(tǒng)，物流系統(tǒng)，卡券系統(tǒng)就會交互協(xié)作。這樣吸積的復(fù)雜性，由于交互特性的出現(xiàn)，會呈現(xiàn)幾何級數(shù)上升。
不合理的業(yè)務(wù)封裝：不合理的業(yè)務(wù)封裝是一個相對寬泛的概念，其具體的表現(xiàn)譬如面向過程而不是對象、分層不合理等。
缺乏統(tǒng)一語言：典型的敏捷開發(fā)的結(jié)構(gòu)，流水線上的各個角色往往會專注于自己負(fù)責(zé)的環(huán)節(jié)，精細(xì)化的分工也限制了每個角色的全局視角；雖然我們經(jīng)常提倡所謂的主人翁意識，但是在落地時又很難去推進。
復(fù)雜性的應(yīng)對永遠(yuǎn)不會是一勞永逸，我們需要不斷地推陳出新，是動態(tài)、漸進的重塑自己對軟件系統(tǒng)的認(rèn)識，不斷認(rèn)識問題和尋找更優(yōu)解的持續(xù)迭代。第一個控制復(fù)雜性的途徑是代碼簡單，意圖清晰（Obvious）。例如: 減少特殊場景的處理，或變量命名一致性都能降低系統(tǒng)復(fù)雜性。另一種方式就是對復(fù)雜問題的抽象然后分而治之。
本部分節(jié)選自《領(lǐng)域驅(qū)動設(shè)計》
DDD 領(lǐng)域驅(qū)動設(shè)計，起源于 2004 年著名建模專家 Eric Evans 發(fā)表的他最具影響力的著名書籍：《Domain-Driven Design – Tackling Complexity in the Heart of Software》，Eric Evans 在該書中只是提供了一套原始理論，并沒有提供一套方法論，因此多年來對于 DDD 也是見仁見智。更早些時候 MartinFowler 曾經(jīng)提出貧血模型與充血模型的概念，他認(rèn)為我們大多數(shù)系統(tǒng)以 POJO 作為模型，只有普通的 getter、setter 方法，沒有真正的行為，好像缺少血液的人，在 Evans 看來，DDD 中模型都是以充血形式存在，也就是說在 DDD 中，我們設(shè)計的模型不僅包含描述業(yè)務(wù)屬性，還要包含能夠描述動作的方法，不同的是，領(lǐng)域中一些概念不能用在模型對象，如倉儲、工廠、服務(wù)等，如強加于模型中，將破壞模型的定義。
領(lǐng)域驅(qū)動設(shè)計的戰(zhàn)略核心即是將問題域與應(yīng)用架構(gòu)相剝離，將業(yè)務(wù)語義顯現(xiàn)化，把原先晦澀難懂的業(yè)務(wù)算法邏輯，通過領(lǐng)域?qū)ο螅―omain Object），統(tǒng)一語言（Ubiquitous Language）轉(zhuǎn)化為領(lǐng)域概念清晰的顯性化表達(dá)出來。
統(tǒng)一語言，軟件的開發(fā)人員/使用人員都使用同一套語言，即對某個概念，名詞的認(rèn)知是統(tǒng)一的，建立清晰的業(yè)務(wù)模型，形成統(tǒng)一的業(yè)務(wù)語義。將模型作為語言的支柱。確保團隊在內(nèi)部的所有交流中，代碼中，畫圖，寫東西，特別是講話的時候都要使用這種語言。例如賬號，轉(zhuǎn)賬，透支策略，這些都是非常重要的領(lǐng)域概念，如果這些命名都和我們?nèi)粘Ｓ懻撘约?PRD 中的描述保持一致，將會極大提升代碼的可讀性，減少認(rèn)知成本。。比如不再會有人在會議中對“工單”、“審核單”、“表單”而反復(fù)確認(rèn)含義了，DDD 的模型建立不會被 DB 所綁架。
面向領(lǐng)域，業(yè)務(wù)語義顯性化，以領(lǐng)域去思考問題，而不是模塊。將隱式的業(yè)務(wù)邏輯從一推 if-else 里面抽取出來，用通用語言去命名、去寫代碼、去擴展，讓其變成顯示概念；很多重要的業(yè)務(wù)概念，按照事務(wù)腳本的寫法，其含義完全淹沒在代碼邏輯中沒有突顯出來。
本部分節(jié)選自《微服務(wù)與云原生》
在 Web 應(yīng)用程序發(fā)展的早期，大部分工程是將所有的服務(wù)端功能模塊打包到單個巨石型（Monolith）應(yīng)用中，譬如很多企業(yè)的 Java 應(yīng)用程序打包為 war 包，最終會形成如下的架構(gòu)：
巨石型應(yīng)用易于搭建開發(fā)環(huán)境、易于測試、易于部署；其缺陷也非常明顯，無法進行局部改動與部署，編譯時間過長，回歸測試周期過長，開發(fā)效率降低等。集中式架構(gòu)分為標(biāo)準(zhǔn)的三層：數(shù)據(jù)訪問層、服務(wù)層和 Web 層。
在 Web2.0 時代剛剛流行的時候，互聯(lián)網(wǎng)應(yīng)用與企業(yè)級應(yīng)用并沒有本質(zhì)的區(qū)別，集中式架構(gòu)分為標(biāo)準(zhǔn)的三層：數(shù)據(jù)訪問層、服務(wù)層和 Web 層。
SOA（Service-Oriented Architecture） 面向服務(wù)架構(gòu)，是在互聯(lián)網(wǎng)應(yīng)用規(guī)模迅速增長，集中式架構(gòu)已無法做到無限制地提升系統(tǒng)的吞吐量的背景下，產(chǎn)生的涉及模塊化開發(fā)、分布式擴展部署等相對寬泛的概念。
SOA 是一個組件模型，它將應(yīng)用程序的不同功能單元（稱為服務(wù)）通過這些服務(wù)之間定義良好的接口和契約聯(lián)系起來。SOA 中的接口獨立于實現(xiàn)服務(wù)的硬件平臺、操作系統(tǒng)和編程語言，采用中立的方式進行定義。這使得構(gòu)建在各種各樣的系統(tǒng)中的服務(wù)可以以一種統(tǒng)一和通用的方式進行交互。面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進行分布式部署、組合和使用。服務(wù)層是 SOA 的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。
實施 SOA 的關(guān)鍵目標(biāo)是實現(xiàn)企業(yè) IT 資產(chǎn)的最大化作用。要實現(xiàn)這一目標(biāo)，就要在實施 SOA 的過程中牢記以下特征：可從企業(yè)外部訪問、隨時可用、粗粒度的服務(wù)接口分級、松散耦合、可重用的服務(wù)、服務(wù)接口設(shè)計管理、標(biāo)準(zhǔn)化的服務(wù)接口、支持各種消息模式、精確定義的服務(wù)契約。
服務(wù)消費者（Service Consumer）可以通過發(fā)送消息來調(diào)用服務(wù)，這些消息由一個服務(wù)總線（Service Bus）轉(zhuǎn)換后發(fā)送給適當(dāng)?shù)姆?wù)實現(xiàn)。這種服務(wù)架構(gòu)可以提供一個業(yè)務(wù)規(guī)則引（Business Rules Engine），該引擎容許業(yè)務(wù)規(guī)則被合并在一個服務(wù)里或多個服務(wù)里。這種架構(gòu)也提供了一個服務(wù)管理基礎(chǔ)（Service Management Infrastructure），用來管理服務(wù)，類似審核，列表（billing），日志等功能。此外，該架構(gòu)給企業(yè)提供了靈活的業(yè)務(wù)流程，更好地處理控制請求（Regulatory Requirement），例如 Sarbanes Oxley（SOX），并且可以在不影響其他服務(wù)的情況下更改某項服務(wù)。
由于分布式系統(tǒng)十分復(fù)雜，因此產(chǎn)生了大量的用于簡化分布式系統(tǒng)開發(fā)的分布式中間件和分布式數(shù)據(jù)庫，服務(wù)化的架構(gòu)設(shè)計理念也被越來越多的公司所認(rèn)同。如下是 Dubbo 官方文檔公布了一張有關(guān) SOA 系統(tǒng)演化過程的圖片：
微服務(wù)（Microservices Architecture Pattern）由 Martin Fowler 在 2014 年提出的，是希望將某個單一的單體應(yīng)用，轉(zhuǎn)化為多個可以獨立運行、獨立開發(fā)、獨立部署、獨立維護的服務(wù)或者應(yīng)用的聚合，從而滿足業(yè)務(wù)快速變化及分布式多團隊并行開發(fā)的需求。如康威定律（Conway’s Law）所言，任何組織在設(shè)計一套系統(tǒng)（廣義概念）時，所交付的設(shè)計方案在結(jié)構(gòu)上都與該組織的通信結(jié)構(gòu)保持一致，微服務(wù)與微前端不僅僅是技術(shù)架構(gòu)的變化，還包含了組織方式、溝通方式的變化。
對于微服務(wù)，不同背景的人也有不同的見解，對于熟悉 SOA 的開發(fā)者，微服務(wù)也可以認(rèn)為是去除了 ESB 的 SOA 的一種實現(xiàn)方案；ESB 是 SOA 架構(gòu)中的中心總線，設(shè)計圖形應(yīng)該是星形的，而微服務(wù)是去中心化的分布式軟件架構(gòu)。SOA 更多強調(diào)重用，而微服務(wù)偏向于重寫。SOA 偏向水平服務(wù)，微服務(wù)偏向垂直服務(wù)；SOA 偏向自上而下的設(shè)計，微服務(wù)偏向自下而上的設(shè)計。
微服務(wù)與微前端原理和軟件工程，面向?qū)ο笤O(shè)計中的原理同樣相通，都是遵循單一職責(zé)(Single Responsibility)、關(guān)注分離(Separation of Concerns)、模塊化(Modularity)與分而治之(Divide & Conquer)等基本的原則。從巨石型應(yīng)用到微服務(wù)的衍化也并非一蹴而就，如下圖也演示了簡單的漸進式替代過程：
云原生是通過構(gòu)建團隊、文化和技術(shù)，利用自動化和架構(gòu)來管理系統(tǒng)的復(fù)雜性和解放生產(chǎn)力。
— Joe Beda，Heotio CTO，聯(lián)合創(chuàng)始人
Pivotal 是云原生應(yīng)用的提出者，并推出了 Pivotal Cloud Foundry 云原生應(yīng)用平臺和 Spring 開源 Java 開發(fā)框架，成為云原生應(yīng)用架構(gòu)中先驅(qū)者和探路者。早在 2015 年 Pivotal 公司的 Matt Stine 寫了一本叫做遷移到云原生應(yīng)用架構(gòu)的小冊子，其中探討了云原生應(yīng)用架構(gòu)的幾個主要特征：符合 12 Factors 應(yīng)用、面向微服務(wù)架構(gòu)、自服務(wù)敏捷架構(gòu)、基于 API 的協(xié)作以及抗脆弱性。2015 年 Google 主導(dǎo)成立了云原生計算基金會（CNCF），起初 CNCF 對云原生（Cloud Native）的定義包含以下三個方面：應(yīng)用容器化、面向微服務(wù)架構(gòu)、應(yīng)用支持容器的編排調(diào)度。
云原生應(yīng)用程序簡單地定義為從頭開始為云計算架構(gòu)而構(gòu)建應(yīng)用程序；這意味著，如果我們將應(yīng)用程序設(shè)計為預(yù)期將部署在分布式、可擴展的基礎(chǔ)架構(gòu)上，我們的應(yīng)用程序就是云原生的。隨著公共云將承載越來越多的算力，未來云計算將是主流的 IT 能力交付方式，CNCF 也對云原生進行了重新定義：云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴展的應(yīng)用；云原生的代表技術(shù)包括容器、服務(wù)網(wǎng)格、微服務(wù)、不可變基礎(chǔ)設(shè)施和聲明式 API。
Codeless 對應(yīng)的是服務(wù)開發(fā)，實現(xiàn)了源代碼托管，你只需要關(guān)注你的代碼實現(xiàn)，而不需要關(guān)心你的代碼在哪，因為在整個開發(fā)過程中你都不會感受到代碼庫和代碼分支的存在。
Applicationless 對應(yīng)的是服務(wù)發(fā)布，在服務(wù)化框架下，你的服務(wù)發(fā)布不再需要申請應(yīng)用，也不需要關(guān)注你的應(yīng)用在哪。
這些技術(shù)組合搭配，能夠構(gòu)建容錯性好、易于管理和便于觀察的松耦合系統(tǒng)；再結(jié)合可靠的自動化手段，云原生技術(shù)能夠使工程師輕松地對系統(tǒng)作出頻繁和可預(yù)測的重大變更。由此可見，云原生是保障系統(tǒng)能力靈動性地有效抓手；云原生技術(shù)有利于各組織在公有云、私有云和混合云等新型動態(tài)環(huán)境中，構(gòu)建和運行可彈性擴展的應(yīng)用。微服務(wù)架構(gòu)非常適合云原生應(yīng)用程序；但是，云原生同樣存在著一定的限制，如果你的云原生應(yīng)用程序部署在 AWS 等公有云上，則云原生 API 不是跨云平臺的。
云原生應(yīng)用的關(guān)鍵屬性包括了：使用輕量級的容器打包、使用最合適的語言和框架開發(fā)、以松耦合的微服務(wù)方式設(shè)計、以 API 為中心的交互和協(xié)作、無狀態(tài)和有狀態(tài)服務(wù)在架構(gòu)上界限清晰、不依賴于底層操作系統(tǒng)和服務(wù)器、部署在自服務(wù)、彈性的云基礎(chǔ)設(shè)施上、通過敏捷的 DevOps 流程管理、自動化能力、通過定義和策略驅(qū)動的資源分配。云原生是分布式應(yīng)用當(dāng)下重要的發(fā)展路徑，其終態(tài)應(yīng)當(dāng)是 Distributionless，所有與分布式相關(guān)的問題由云平臺解，分布式應(yīng)用的開發(fā)會跟傳統(tǒng)應(yīng)用的開發(fā)一樣方便，甚至更加便捷。
本部分節(jié)選自《分布式基礎(chǔ)架構(gòu)之虛擬化與編排》
虛擬機由某些特定的硬件和內(nèi)核虛擬化組成，運行客戶操作系統(tǒng)。稱為管理程序的軟件創(chuàng)建虛擬化硬件，其可以包括虛擬磁盤，虛擬網(wǎng)絡(luò)接口，虛擬 CPU 等。虛擬機還包括可以與此虛擬硬件通信的賓客內(nèi)核。管理程序可以托管，這意味著它是一些在主機操作系統(tǒng)（MacOS）上運行的軟件，如示例中所示。它也可以是裸機，直接在機器硬件上運行（替換你的操作系統(tǒng)）。無論哪種方式，管理程序方法都被認(rèn)為是重量級的，因為它需要虛擬化多個部分（如果不是全部硬件和內(nèi)核）。
VM 需要硬件虛擬化才能實現(xiàn)機器級隔離，而容器則只需要在同一操作系統(tǒng)內(nèi)進行隔離操作。 隨著隔離空間數(shù)量的增加，開銷差異變得非常明顯。
在過去幾年里，云平臺發(fā)展迅速，但其中困擾運維工程師最多的，是需要為各種迥異的開發(fā)語言安裝相應(yīng)的運行時環(huán)境。雖然自動化運維工具可以降低環(huán)境搭建的復(fù)雜度，但仍然不能從根本上解決環(huán)境的問題。
Docker 的出現(xiàn)成為了軟件開發(fā)行業(yè)新的分水嶺，容器技術(shù)的成熟也標(biāo)志著技術(shù)新紀(jì)元的開啟。Docker 提供了讓開發(fā)工程師可以將應(yīng)用和依賴封裝到一個可移植的容器中的能力，這項舉措使得 Docker 大有席卷整個軟件行業(yè)并且進而改變行業(yè)游戲規(guī)則的趨勢，這像極了當(dāng)年智能手機剛出現(xiàn)時的場景——改變了整個手機行業(yè)的游戲規(guī)則。Docker 通過集裝箱式的封裝方式，讓開發(fā)工程師和運維工程師都能夠以 Docker 所提供的鏡像分發(fā)的標(biāo)準(zhǔn)化方式發(fā)布應(yīng)用，使得異構(gòu)語言不再是捆綁團隊的枷鎖。
容器是包含應(yīng)用程序代碼，配置和依賴關(guān)系的軟件包，可提供運營效率和生產(chǎn)力。容器為我們提供了可預(yù)測的，可重復(fù)的和不可變的運行預(yù)期，容器的興起是 DevOps 即服務(wù)的一個巨大推動因素，可以克服當(dāng)今面臨的最大安全障礙。容器化通過在操作系統(tǒng)級別進行虛擬化來使應(yīng)用程序可移植，從而創(chuàng)建基于內(nèi)核的隔離的封裝系統(tǒng)。容器化的應(yīng)用程序可以放在任何地方，無需依賴項運行或需要整個 VM，從而消除了依賴關(guān)系。
作為獨立的單元，容器能夠在任何主機操作系統(tǒng)，CentOS，Ubuntu，MacOS，甚至是像 Windows 這樣的非 UNIX 系統(tǒng)中運行。容器還充當(dāng)標(biāo)準(zhǔn)化的工作或計算單元。一個常見的范例是每個容器運行單個 Web 服務(wù)器，數(shù)據(jù)庫的單個分片或單個 Spark 工作程序等，只需要擴展容器的數(shù)量就能夠便捷地擴展應(yīng)用。每個容器都有一個固定的資源配置（CPU，RAM，線程數(shù)等），并且擴展應(yīng)用程序需要只擴展容器的數(shù)量而不是單個資源原語。當(dāng)應(yīng)用程序需要按比例放大或縮小時，這為工程師提供了更容易的抽象。容器也是實現(xiàn)微服務(wù)架構(gòu)的一個很好的工具，每個微服務(wù)只是一組協(xié)作容器。例如，可以使用單個主容器和多個從容器來實現(xiàn) Redis 微服務(wù)。
隨著虛擬化技術(shù)的成熟和分布式架構(gòu)的普及，用來部署、管理和運行應(yīng)用的云平臺被越來越多地提及。IaaS、PaaS 和 SaaS 是云計算的三種基本服務(wù)類型，分別表示關(guān)注硬件基礎(chǔ)設(shè)施的基礎(chǔ)設(shè)施即服務(wù)、關(guān)注軟件和中間件平臺的平臺即服務(wù)，以及關(guān)注業(yè)務(wù)應(yīng)用的軟件即服務(wù)。容器的出現(xiàn)，使原有的基于虛擬機的云主機應(yīng)用，徹底轉(zhuǎn)變?yōu)楦屿`活和輕量的容器與編排調(diào)度的云平臺應(yīng)用。
然而容器單元越來越散落使得管理成本逐漸上升，大家對容器編排工具的需求前所未有的強烈，Kubernetes、Mesos、Swarm 等為云原生應(yīng)用提供了強有力的編排和調(diào)度能力，它們是云平臺上的分布式操作系統(tǒng)。容器編排是通常可以部署多個容器以通過自動化實現(xiàn)應(yīng)用程序的過程。像 Kubernetes 和 Docker Swarm 這樣的容器管理和容器編排引擎，使用戶能夠指導(dǎo)容器部署并自動執(zhí)行更新，運行狀況監(jiān)視和故障轉(zhuǎn)移過程。
Kubernetes 是目前世界范圍內(nèi)關(guān)注度最高的開源項目，它是一個出色的容器編排系統(tǒng)，用于提供一站式服務(wù)。Kubernetes 出身于互聯(lián)網(wǎng)行業(yè)巨頭 Google，它借鑒了由上百位工程師花費十多年時間打造的 Borg 系統(tǒng)的理念，安裝極其簡易，網(wǎng)絡(luò)層對接方式十分靈活。Kubernetes 和 Mesos 的出色表現(xiàn)給行業(yè)中各類工程師的工作模式帶來了顛覆性的改變。他們再也不用關(guān)注每一臺服務(wù)器，當(dāng)服務(wù)器出現(xiàn)問題時，只要將其換掉即可。業(yè)務(wù)開發(fā)工程師不必再過分關(guān)注非功能需求，只需專注自己的業(yè)務(wù)領(lǐng)域即可。而中間件開發(fā)工程師則需要開發(fā)出健壯的云原生中間件，用來連接業(yè)務(wù)應(yīng)用與云平臺。
Kubernetes、Service Mesh 和 Serverless 三者共同演繹不同層次的封裝和向上屏蔽下面的細(xì)節(jié)。Kubernetes 引入了不同的設(shè)計模式，實現(xiàn)對各種云資源全新、有效和優(yōu)雅的抽象和管理模式，讓集群的管理和應(yīng)用發(fā)布變成了件相當(dāng)輕松且不易出錯的事。被廣泛采用的微服務(wù)軟件架構(gòu)將分布式應(yīng)用的各種復(fù)雜度遷移到了服務(wù)之間，如何通過全局一致、體系化、規(guī)范化和無侵入的手段進行治理就變成了微服務(wù)軟件架構(gòu)下至關(guān)重要的內(nèi)容。Kubernetes 細(xì)化的應(yīng)用程序的分解粒度，同時將服務(wù)發(fā)現(xiàn)、配置管理、負(fù)載均衡和健康檢查等作為基礎(chǔ)設(shè)施的功能，簡化了應(yīng)用程序的開發(fā)。而 Kubernetes 這種聲明式配置尤其適合 CI/CD 流程，況且現(xiàn)在還有如 Helm、Draft、Spinnaker、Skaffold 等開源工具可以幫助我們發(fā)布 Kuberentes 應(yīng)用。
Service Mesh 通過將各服務(wù)所共用和與環(huán)境相關(guān)的內(nèi)容剝離到部署于每個服務(wù)邊上的 Sidecar 進程而輕松地做到了。這一剝離動作使得服務(wù)與平臺能充分解耦而方便各自演進與發(fā)展，也使得服務(wù)變輕而有助于改善服務(wù)啟停的及時性。Service Mesh 因為將那些服務(wù)治理相關(guān)的邏輯剝離到了 Sidecar 中且作為獨立進程，所以 Sidecar 所實現(xiàn)的功能天然地支持多語言，為上面的服務(wù)采用多語言開發(fā)創(chuàng)造了更為有利的條件。通過 Service Mesh 對整個網(wǎng)絡(luò)的服務(wù)流量進行技術(shù)收口，讓異地多活這樣涉及流量調(diào)度的系統(tǒng)工程實現(xiàn)起來更加優(yōu)雅、簡潔與有效，也能更加方便地實現(xiàn)服務(wù)版本升級時的灰度、回滾而改善安全生產(chǎn)質(zhì)量。由于技術(shù)收口，給服務(wù)流量的治理和演進、排錯、日志采集的經(jīng)濟性等疑難問題創(chuàng)造了新的發(fā)展空間。
您可以通過以下導(dǎo)航來在 Gitbook 中閱讀筆者的系列文章，涵蓋了技術(shù)資料歸納、編程語言與理論、Web 與大前端、服務(wù)端開發(fā)與基礎(chǔ)架構(gòu)、云計算與大數(shù)據(jù)、數(shù)據(jù)科學(xué)與人工智能、產(chǎn)品設(shè)計等多個領(lǐng)域：
知識體系：《Awesome Lists | CS 資料集錦》、《Awesome CheatSheets | 速學(xué)速查手冊》、《Awesome Interviews | 求職面試必備》、《Awesome RoadMaps | 程序員進階指南》、《Awesome MindMaps | 知識脈絡(luò)思維腦圖》、《Awesome-CS-Books | 開源書籍（.pdf）匯總》
編程語言：《編程語言理論》、《Java 實戰(zhàn)》、《JavaScript 實戰(zhàn)》、《Go 實戰(zhàn)》、《Python 實戰(zhàn)》、《Rust 實戰(zhàn)》
軟件工程、模式與架構(gòu)：《編程范式與設(shè)計模式》、《數(shù)據(jù)結(jié)構(gòu)與算法》、《軟件架構(gòu)設(shè)計》、《整潔與重構(gòu)》、《研發(fā)方式與工具》
Web 與大前端：《現(xiàn)代 Web 開發(fā)基礎(chǔ)與工程實踐》、《數(shù)據(jù)可視化》、《iOS》、《Android》、《混合開發(fā)與跨端應(yīng)用》
服務(wù)端開發(fā)實踐與工程架構(gòu)：《服務(wù)端基礎(chǔ)》、《微服務(wù)與云原生》、《測試與高可用保障》、《DevOps》、《Node》、《Spring》、《信息安全與***測試》
分布式基礎(chǔ)架構(gòu)：《分布式系統(tǒng)》、《分布式計算》、《數(shù)據(jù)庫》、《網(wǎng)絡(luò)》、《虛擬化與編排》、《云計算與大數(shù)據(jù)》、《Linux 與操作系統(tǒng)》
數(shù)據(jù)科學(xué)，人工智能與深度學(xué)習(xí)：《數(shù)理統(tǒng)計》、《數(shù)據(jù)分析》、《機器學(xué)習(xí)》、《深度學(xué)習(xí)》、《自然語言處理》、《工具與工程化》、《行業(yè)應(yīng)用》
產(chǎn)品設(shè)計與用戶體驗：《產(chǎn)品設(shè)計》、《交互體驗》、《項目管理》
此外，你還可前往 xCompass 交互式地檢索、查找需要的文章/鏈接/書籍/課程；或者在 MATRIX 文章與代碼索引矩陣中查看文章與項目源代碼等更詳細(xì)的目錄導(dǎo)航信息。最后，你也可以關(guān)注微信公眾號：『某熊的技術(shù)之路』以獲取最新資訊。
免責(zé)聲明：本站發(fā)布的內(nèi)容（圖片、視頻和文字）以原創(chuàng)、轉(zhuǎn)載和分享為主，文章觀點不代表本網(wǎng)站立場，如果涉及侵權(quán)請聯(lián)系站長郵箱：is@yisu.com進行舉報，并提供相關(guān)證據(jù)，一經(jīng)查實，將立刻刪除涉嫌侵權(quán)內(nèi)容。
億速云公眾號
手機網(wǎng)站二維碼
