1.5 互聯網核心架構的演變

移動互聯網的普及，使C端客戶有了爆發性的增長，原有的面向企業內部的系統，現在要面向互聯網受眾，對系統的要求有了根本性的改變，系統的復雜度大幅提高。最直觀的體現是在軟件工程中組織結構分工更細，責任更加明確。在早期的軟件開發過程中，一個好的項目骨干甚至可以承擔從需求調研到界面設計、技術開發等全部工作，而現在的互聯網軟件開發包括了前端工程師、后端工程師、產品設計師等等不同的工種。在技術架構上也經歷了類似的歷程。系統架構從早期的大包大攬的單體架構，逐漸演變到基于微服務的架構，乃至應用云的架構。系統架構的演變過程見圖1-5。

如圖1-5所示，系統架構的演變經歷了如下過程。

■ 最早期的應用是以CS架構為主的，稍后逐漸發展為BS架構。BS架構在服務端是一個大包大攬的all in one的架構，所有的服務功能在一個應用內。

■ 單體應用出現性能問題時，通過水平復制應用，在前端通過Nginx進行反向代理，實現負載均衡。

■ 單個應用的復制解決不了問題，此時將巨大的單體拆分成多個系統，多個系統間通過服務調用協同解決問題，所以又提出了面向服務的架構。

■ 隨著系統服務數量的增多，需要通過服務治理手段，管理企業系統內部各應用間的互聯互通，這就形成了以ESB為核心的架構。

■ 隨著移動互聯網的發展，產生了微服務的架構。微服務架構就是技術架構更加專業化、精細化的表現，是在業務服務化的基礎上對服務的更加精細化管理的架構。

■ 微服務架構采用侵入性設計，不支持多語言，因此產生了Service Mesh（服務網格）架構，通過抽象出負責網絡通信的“Sidecar”，將業務邏輯與服務治理完全分隔。

■ 云原生架構，完全基于云平臺的彈性計算能力的架構，應用系統在最初就基于云進行設計，并在云上以最佳方式開發、測試、部署和維護。

1.5.1 Monolith單體架構

一個單體應用系統是以一個單個單元的方式來構建的。一個BS架構的應用系統經常包含三個主要部分：客戶端用戶界面、數據庫和服務端應用系統。服務器端所有的功能打包在一個WAR包里，部署在一個JEE容器（Tomcat，JBoss，WebLogic）中，基本沒有外部依賴（除了容器）。單體架構強調內部垂直分層，如MVC結構，包括展示層、控制層、數據層。該系統的任何改變，都會涉及構建和部署上述服務端應用系統的一個新版本。

單體架構有很多好處：處理用戶請求的所有邏輯都運行在一個單個的進程內，因此能使用編程語言的基本特性，把應用系統劃分為類、函數和命名空間；容易測試，在開發人員的筆記本電腦上就可以運行和測試這樣的應用系統；容易部署，直接打包為一個完整的包，復制到Web容器的某個目錄下即可運行；容易擴展，通過負載均衡器運行許多實例，將這個單體應用進行橫向擴展。

單體應用系統可以被成功地實現，但是隨著越來越多的功能被部署到服務端，對于大規模的復雜應用，單體架構應用會顯得特別笨重。軟件變更受到了很大的限制，應用系統中一個很小的變更，也需要將整個單體應用系統進行重新構建和部署，編譯時間過長，回歸測試周期過長，開發效率降低。單體架構也不利于更新技術框架，除非你愿意將系統全部重寫。隨著時間的推移，單體應用逐漸難以保持良好的模塊化結構，這使得它越來越難以將一個模塊的變更產生的影響控制在該模塊內，當對系統進行擴展時，不得不擴展整個應用系統，而不能僅擴展該系統中需要更多資源的那些部分。

1.5.2 Microservice微服務架構

單體架構在擴展時無法實現對業務的精細化管理。如圖1-6所示，一個應用中，在同一個WAR包中打包了數個業務，其中某個業務的負載已經達到了90%，而同一應用下的其他三個組成的負載較低。因此添加一個額外的應用實例雖然可以將需要擴容的業務的負載降低到45%，但是也使得其他各業務的利用率更為低下。解決之道就是Microservice，即微服務架構。

Martin Fowler在ThoughtWorks提出了Microservice的架構，對Microservice是這樣定義的：Microservice體系結構風格是一種將單個應用程序開發為一組小型服務的方法，每個服務都在自己的進程中運行，并與輕量級機制（通常是HTTP）通信。這些服務是圍繞業務能力構建的，可以通過完全自動化的部署機制進行獨立部署。對這些服務的集中管理是最低限度的，這些服務可以用不同的編程語言編寫，并使用不同的數據存儲技術。

如圖1-7所示，在開始階段使用Microservice架構模式開發應用的效率低于Monolith。但是隨著應用規模的增大，基于Microservice架構模式的開發效率將明顯上升，而基于Monolith模式開發的效率將逐步下降。

在開發初期，Microservice的復雜性會導致開發效率較低，隨著規模的擴大，由于Microservice架構模式中依賴的子服務已經完成，開發過程通常只需要關注自身的業務邏輯即可提高開發效率。而隨著Monolith模式中應用的功能逐漸變大，增加一個新的功能會影響到該應用中的很多方面，因此其開發效率會越來越低。

Microservice背后的理念是將大型、復雜且歷時長久的應用在架構上設計為內聚的服務，這些服務能夠隨著時間的流逝而演化。服務分割的粒度是面向服務架構中首要考慮的因素。如果一個服務的粒度太小，會導致頻繁的調用，導致服務的嵌套調用，使調用過程中網絡消耗占比較高，得不償失。服務粒度太大，又失掉靈活性。在Microservice架構模式中，需要站在最終用戶的視角分割服務，一個服務需要能夠獨立地完成特定的業務邏輯，至少是某個獨立資源的CRUD操作。例如在電子商務網站中，需要一個創建訂單服務，一個查詢訂單服務，一個取消訂單服務等。Microservice的最好例子就是UNIX的各種命令，如find、grep等。

Microservice這個術語強烈建議服務應該是很小的，一個原子服務不應該消耗很多的資源，如不應在一個原子服務中進行跨庫操作。在涉及用戶交互時，常常為了減少前端的調用，需要提供一個組合服務，負責組裝多個原子服務。組合服務可能涉及多個數據庫的操作，使用分布式事務存在較大風險，一般情況下可以考慮使用數據最終一致性的方案。

其他Microservice架構需要考慮的基本問題包括：服務提供者如何注冊服務，消費者如何找到服務提供者；服務消費者與服務提供者之間如何通信，是同步還是異步，采用什么樣的協議；在一個服務的多個實例間如何進行負載均衡，消費者實現還是服務提供者實現，都有哪些負載均衡策略；怎樣保證系統健壯，將壞服務的影響降到最低，實現限流、熔斷、降級等機制；從服務的消費、調用乃至嵌套調用過程中如何跟蹤服務的調用過程，判斷服務消耗時間，做好服務監控。

顯而易見，Microservice模式帶來了較大的架構復雜性。在《Introduction to Microservices》這篇文章中對Microservice的優點和缺點有系統的描述。

Microservice架構的優點包括復雜度可控、獨立按需擴展、技術選型靈活、容錯和可用性更高。

■ 通過分解巨大的單體式應用為多個服務方法解決了單體應用的開發維護等復雜問題。在功能不變的情況下，應用被分解為多個可管理的分支或服務。每個服務都有一個用RPC或者消息驅動API定義清楚的邊界。每個服務都更容易開發、理解和維護，提供了模塊化的解決方案。

■ 這種架構使得每個服務都可以由專門開發團隊來開發，帶來了組織結構的自主性。開發者可以自由選擇開發技術，提供API服務。當然，許多公司試圖避免混亂，只提供某些技術選擇。這種自由意味著開發者不需要被迫使用某項目開始時采用的過時技術，他們可以選擇現在的技術。甚至，因為服務相對簡單，即使使用新技術重寫以前的代碼也不是很困難的事情。

■ Microservice架構模式使每個微服務都能獨立部署。開發人員不需要協調部署本地服務的變更。這些變化可以在測試后盡快部署。例如，UI團隊可以執行A/B測試，并快速迭代UI更改。Microservice架構模式使連續部署成為可能。

■ Microservice架構模式使每個服務都可以獨立調整。可以根據每個服務的實際需求來調整服務實例的數量，也可以使用最符合服務資源要求的硬件。

Microservice的主要缺點是精細化管理產生的復雜性，包括服務間通信成本、數據一致性、系統部署依賴、集成測試規模、多服務運維難度、性能監控等問題。

■ 開發人員需要選擇和實現基于消息傳遞或RPC的進程間通信機制。此外，他們還必須編寫代碼來處理部分故障，因為請求的服務器提供者可能響應很慢或不可用。

■ Microservice應用是分布式系統，由此會帶來固有的復雜性。開發者使用RPC或者消息傳遞機制實現進程間通信，需要處理消息內容重復和信息順序混亂等問題。

■ Microservice的另一個挑戰是分區數據庫架構。在基于微服務的應用程序中，常常需要更新不同服務所擁有的多個數據庫，使用分布式事務通常不是一個好的選擇，最后不得不使用最終一致性的方法。

■ 測試Microservice應用程序也更復雜。測試一個基于微服務架構的應用也是很復雜的任務。相比單體應用，同樣的服務測試需要啟動和它有關的所有服務，測試需要覆蓋不同服務間的可靠性等問題。

■ 在Microservice架構模式下，應用的改變會波及多個服務。例如，假設要完成一個案例，需要修改服務A、B、C，而A依賴B，B依賴C。在單體式應用中，只需要改變相關模塊，整合變化，就部署好了。相比之下，微服務架構模式就需要考慮相關改變對不同服務的影響。例如，需要更新服務C，然后是B，最后才是A，幸運的是，許多改變一般只影響一個服務，而需要協調多服務的改變很少。

■ 部署基于Microservice的應用程序也更復雜。單一應用程序只需要簡單地部署在負載平衡器后面的一組相同的服務器上。每個應用程序實例都配置有相同的基礎元數據（如數據庫和消息代理的主機和端口）。相比之下，微服務應用通常由大量服務組成。每個服務將有多個運行時實例。更多的部件需要進行配置、部署、擴展和監控。此外，還需要實現服務發現機制，使服務能夠發現需要與之通信的任何其他服務的位置（主機和端口）。傳統的基于手動操作的方法無法擴展到這種復雜程度。因此，成功部署微服務應用程序需要開發人員更好地控制部署方法，并實現高水平的自動化。

1.5.3 Microservice與SOA

1.SOA架構

面向服務的架構（Service Oriented Architecture，SOA）是指系統由多個服務組成，服務通常以獨立的形式存在于操作系統進程中，各個服務之間通過網絡進行調用，服務之間通過相互依賴最終提供一系列的功能。

2.SOA主要解決的問題

業務系統集成化：整體解決企業系統間的通信問題，通過引入ESB、技術規范、服務規范等技術，把原先散亂并且無規劃的網狀系統結構，梳理成規整且可治理的星形系統結構。

業務功能服務化：把業務邏輯抽象成可復用、可組裝的服務，通過服務的編排實現業務的快速再生，把原先固有的業務功能轉變為通用的業務服務，實現業務邏輯的快速復用。

3.SOA與ESB

SOA一般使用ESB（企業服務總線）作為核心架構，ESB是將傳統的單點集成轉化為總線式集成的核心部件，它集成不同系統不同協議的服務，連接服務節點，通過信息的轉化和路由使服務互聯互通，是企業內部業務系統間業務協同和數據集成的高速公路。ESB一般采用集中式轉發請求，適合大量異構系統集成。通過把系統里的集成邏輯單拉出來，放到ESB中部署，并與應用系統適配，讓應用系統變得只有自己的業務邏輯，應用系統簡單、輕薄。但所有的服務上增加了一個ESB總線作為溝通的渠道，對于較大的并發，會將瓶頸推到ESB總線上。很多時候，ESB總線都采用MQ消息隊列服務異步處理來緩解壓力。

ESB的主要功能包括：格式轉換、協議轉換、服務代理、服務編排、安全控制、系統監控、路由轉發等。ESB產品的代表有：JBoss ESB，Mule，Camel等中間件。JBoss的ESB組件見圖1-8。

4.Microservice與SOA

技術架構都是業務驅動的，SOA與Microservice是不同時代需求背景的產物。

大型企業內部信息系統關系錯綜復雜，需要對服務進行編排集成，因此產生了以ESB為核心的SOA架構。如圖1-9和圖1-10所示，Apache的路由中間件Camel支持50種集成模式、80多種協議規范與通信連接、19種數據格式和15種語言。

微服務是互聯網場景下產生的，解決的是互聯網背景下的高并發、快迭代的問題。微服務是SOA的傳承，是SOA組件化架構思想的推進，但更強調分布式應用的強健壯、適用于高并發場景。Microservice的主要功能包括服務注冊和發現、服務網關、服務監控、負載均衡、安全控制等。例如使用Microservice中的服務注冊和發現能力，子業務系統可以通過注冊中心很快找到對應的服務，但實際訪問仍然是點對點的服務調用，適合并發及壓力比較大的情況。Microservice中間件的代表包括：Dubbo，HSF，Spring Cloud，Motan等。

SOA與Microservice都著重于服務治理的功能。SOA著重強調規范管理、服務重用和系統協同。SOA中一般提倡ESB，服務規范，WS等概念。嘗試將應用集成，強調服務組合和編排能力，一般采用中央管理模式來確保各應用能夠交互運作。

Microservice以提高服務性能、提供服務健壯性、實現服務自治為主要目的。Microservice傾向于降低中心消息總線（類似于ESB）的依賴，采用分布式的去中心化設計，去掉大一統的ESB，服務間輕通信（REST），不強調服務規范。Microservice不再強調服務組合和編排能力，實踐證明服務組合和編排能力會導致較重的系統架構。微服務架構強調限流容錯，著重于分散管理與自動化部署，單體應用要打散為多個獨立自治并可以在獨立進程中運行和管理的微服務模塊。ESB與Microservice在架構上的區別如圖1-11所示。

1.5.4 Servicemesh服務網格架構

Microservice架構采用了非中心化的設計，但需要提供客戶端組件和服務端組件。客戶端組件嵌入在服務消費者應用程序中，負責從注冊中心及時獲得最新的服務提供者地址，并做負載均衡。服務端組件需要在啟動時向注冊中心注冊自己并定期報告心跳。微服務的架構如圖1-12所示。

在《Pattern：Service Mesh》這篇文章中對微服務架構的缺點和演變進行了解析（見https://philcalcado.com/2017/08/03/pattern_service_mesh.html）。

微服務架構需要在服務消費者進程和服務提供者進程中嵌入代理，這些基礎架構相關的邏輯是與業務架構耦合在一起的，是一種侵入式設計，如圖1-13所示。Spring Cloud的Eureka注冊中心和Ribbon客戶端代理，Dubbo的注冊中心和客戶端都是這種模式的體現。這種設計無法支撐多語言環境，業務架構和基礎架構不能單獨演進。

為了解決這個問題，需要將這些入侵業務架構的功能抽象出來，作為一個獨立的功能。這個獨立的服務被稱為Sidecar，這種模式叫作Sidecar模式，如圖1-14所示。Sidecar模式是一種將應用功能從應用本身剝離出來，作為單獨進程的方式。該模式允許我們向應用無侵入式地添加多種功能，避免了為滿足第三方組件需求而向應用添加額外的配置代碼。就像邊車加裝在摩托車上一樣，在軟件架構中，Sidecar附加到主應用（或者叫父應用）上，以擴展/增強功能特性，Sidecar與主應用是松耦合的。對每個微服務節點，都需要額外部署一個Sidecar來負責業務邏輯外的公共功能，所有的出站入站的網絡流量都會先經過Sidecar進行各種處理或者轉發。微服務的開發不需要考慮業務邏輯外的問題。

在圖1-15中，線條代表了服務間的通信，線條串起來的方塊為Sidecar，Sidecar旁邊的方塊為服務。所有的Sidecar都是一樣的，只需要部署的時候使用編排工具即可方便地為所有節點注入Sidecar，服務之間通過SideCar發現和調用目標服務，從而形成服務之間的網絡狀依賴關系，Service Mesh（服務網格）因此得名。

Service Mesh最早由開發Linkerd（最早實現Service Mesh理念的產品）的Buoyant公司（前Twitter基礎設施工程師創辦）提出，Buoyant公司的CEO William Morgan定義Service Mesh的概念如下：

A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It's responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.

即：服務網格是一個專門處理服務通信的基礎設施層。它的職責是在由云原生應用組成服務的復雜拓撲結構下進行可靠的請求傳送。在實踐中，它是一組和應用服務部署在一起的輕量級的網絡代理，并且對應用服務透明。

通過服務網格可以完成以下事項。

■ 支持多語言，為異構（微）服務框架/平臺提供融合發展的可能。

■ 為單體應用向微服務架構演進提供漸進的途徑。

■ 業務開發聚焦于業務邏輯本身，業務開發時無需關心安全、灰度、限流、熔斷等通用的技術內容。

■ 基礎架構和業務架構可以獨立演進。

■ 對（異構）微服務架構應用實現更為有效的全局一體化監管控。

圖1-16是服務網格框架Istio的示例圖（https://istio.io/docs/examples/bookinfo/）。一個bookinfo視圖，業務邏輯由productPage microService實現，productPage又調用了detailService和不同版本的ReviewsService，ReviewsService又調用了RatingsService，這些不同的服務采用了不同的語言編寫。在應用服務網格框架Istio后，在每個Service側按照Sidecar模式部署了服務代理，既整合了不同語言的服務，又保證了各個服務的獨立演進。

1.5.5 Cloud Native云原生架構

1.云原生的由來

云原生（Cloud Native）的概念，由來自Pivotal的Matt Stine于2013年首次提出。2015年Matt Stine提出了云原生架構應該具備的特征，包括微服務（MicroServices）、敏捷基礎設施（Agile Infrastructure）和12要素（The Twelve-Factor）、基于API的協作、抗脆弱性等幾大主題。

■ 12要素應用程序：云原生應用架構模式的集合。

■ 微服務（MicroServices）：獨立部署的服務，每個服務只做一件事情。

■ 自助服務的敏捷基礎設施：快速，可重復和一致地提供應用環境和后臺服務的平臺。

■ 基于API的協作：發布和版本化的API，允許在云原生應用架構中的服務之間進行交互。

■ 抗壓性：根據壓力變化的系統。

2017年，Matt Stine進一步歸納云原生的特征為：模塊化、可觀察、可部署、可測試、可處理、可替代。

2015年Google主導成立了云原生計算基金會CNCF（Cloud Native Computing Foundation），最初定義云原生應包含應用容器化、面向微服務架構、應用支持容器的編排調度。

2018年，CNCF在云原生定義中加入了serviceMesh。官網（https://github.com/cncf/toc/blob/master/DEFINITION.md）上的定義中英對照如下。

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach. （云原生技術有利于各組織在公有云、私有云和混合云等新型動態環境中，構建和運行可彈性擴展的應用。云原生的代表技術包括容器、服務網格、微服務、不可變基礎設施和聲明式API。）These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil. （這些技術能夠構建容錯性好、易于管理和便于觀察的松耦合系統。結合可靠的自動化手段，云原生技術使工程師能夠輕松地對系統做出頻繁和可預測的重大變更。）

2.云原生的含義

顧名思義，云原生就是應用基于云而生，應用系統在最初就基于云進行設計，并在云上以最佳方式開發、測試、部署和維護。

云原生概念起源于大廠商云平臺的成熟，云計算的3層概念（基礎設施即服務（IaaS）、平臺即服務（PaaS）和軟件即服務（SaaS））已經完善并足以支撐起軟件生命周期的各個環節。

無論如何解釋云原生，其出發點都是為了將業務處理邏輯從其他復雜的事務中干凈徹底地抽象隔離。云原生的各種定義都包含了下列含義。

（1）云原生系統應使用Microservice、service mesh技術，以隔離技術架構對業務處理邏輯的侵入。

使用云原生架構，有必要應用Microservice、service mesh技術。在核心技術架構層使用Microservice這一類架構，一方面提供了松耦合的能夠被獨立開發和部署的無狀態化服務，另一方面提供了完善的服務治理能力，從而使核心業務能夠獨立擴展、升級和可替換，進而應用云基礎設施。

（2）云原生系統應該是面向Iaas、PaaS和SaaS服務設計的，以隔離基礎設施對業務處理的侵入。

云原生開發模式意味著要充分利用基礎設施即服務（IaaS）、平臺即服務（PaaS）和軟件即服務（SaaS）的能力。一方面，云平臺要保證資源的提供能夠實現需求，租戶不需要關注資源的細節情況，并擁有充分的自主能力，構建基礎設施服務于開發、測試、聯調和灰度上線等需求。同時要求業務開發具有較好的架構設計，技術人員使用各個層級的云服務都是通過代碼來完成的，并且是自動化的，不能通過手工安裝或克隆的方式來管理服務器資源。基礎設施通過代碼來進行更改、測試，在每次變更后執行測試的自動化流程中，確保能維護穩定的基礎設施。不需要依賴本地數據進行持久化，所有的資源都是可以隨時拉起，隨時釋放，同時以API的方式提供彈性、按需的計算、存儲能力。

（3）云原生系統應該是有利于DevOps持續集成的，以隔離專業復雜的開發運維管理對業務快速迭代的影響。

云原生開發模式應打破軟件生命周期中各個干系人的隔閡，促進開發部門、運維部門和質量保障部門之間的溝通、協作與整合。通過自動化的方式實現持續集成、持續部署、持續發布，確保持續、快速地完成一個個較小的任務目標，完成從開發和測試，再到代碼快速、安全地部署到產品環境的全流程。每當開發人員提交了一次改動，就立刻進行構建、自動化測試，確保業務應用和服務能符合預期，確保新代碼和原有代碼能正確地集成在一起。在持續集成完成之后，要能夠發送到預發布系統上，達到生產環境的條件，乃至最后將應用安全地部署到產品環境中。云原生模式要打通開發、測試、生產的各個環節，自動、持續、增量地交付產品，容器和容器編排是完成這個自動化過程的基礎。

（4）云原生系統應遵循有利于云原生實施的軟件架構模式。

互聯網應用在設計過程中，需要遵循一些基本原則，以便用好云設施，并通過云原生模式實現從小規模集成單元到復雜的分布式系統的交付過程。主要原則包括：顯式聲明第三方類庫依賴關系；使用環境配置而不是代碼配置；只保持一份基礎代碼；統一且不加區別地對待本地服務和第三方服務；使用網絡通信避免通過本地文件或進程通信；進程無狀態且無共享；應用無狀態能彈性伸縮；區分構建發行與運行的不同配置；研發測試和生產環境相似以利于持續集成；收集日志使系統可視化等。

3.Serverless架構

Serverless直譯為中文是“無服務器”。其含義是指基礎設施租戶只需要管理“服務”，而不需要管理“服務器”，服務器的管理以及資源分配對用戶不可見。另外，對于租戶，Serverless是付完即走，基于實際的消費而不是基于預測的預付款進行收費的。可見，Serverless是云原生思想的一種更為徹底的落地模式。國內外的各大云廠商Amazon、微軟、Google、IBM、阿里云、騰訊云、華為云相繼推出了Serverless產品。

使用Serverless框架之后，應用開發者的整個操作流程就變成了：只需要編寫代碼（或者函數），以及配置文件（如何構建、運行以及訪問等聲明式信息），然后進行非常簡單的build和deploy操作就能把應用自動部署到集群（可以是公有云，也可以是私有的集群），其他事情都是Serverless平臺自動處理的。

■ 自動完成代碼到容器的構建。

■ 把應用（或者函數）和特定的事件進行綁定：當事件發生時，自動觸發應用（或者函數）。

■ 自動的網絡路由和流量控制。

■ 應用的自動伸縮。

Serverless架構的一種典型模式是FaaS（Function as a Service，函數即服務）。例如開發一個圖片上傳和分析的功能，傳統的開發需要關注Tomcat容器，需要MVC架構，而使用FaaS，只需要實現一個Function Handler，處理圖片上傳完成這個事件，在Function Handler中調用圖片識別的相關邏輯，然后調用數據庫的REST API存儲結果。過程中不用構建MVC，不用配置Tomcat的XML文件，數據持久化直接使用對象存儲相關服務。這個應用也不需要7×24小時運行，沒有用戶上傳圖片時它只是一份編譯好的代碼，當用戶圖片上傳完成時，FaaS會為AI應用啟動一個新的進程執行代碼，該進程在代碼執行完成后自動銷毀，應用的所有者只需為代碼執行的這幾十秒鐘付錢，節省了很多開支。也無需操心Auto-Scaling的問題，FaaS會在需要的時候自動擴展。

上述過程中，使用了公共云提供的對象存儲服務，在Serverless架構中也叫BaaS（Backend as a Service，后端即服務）。BaaS是PaaS的一種特例，它們的區別在于：BaaS僅提供應用依賴的第三方服務，而典型的PaaS平臺需要參與應用的生命周期管理，需要提供手段讓開發者部署和配置應用，例如自動將PaaS應用部署到Tomcat容器中，并管理Paas應用的生命周期。BaaS不包含這些內容，BaaS只以API的方式提供應用依賴的后端服務，例如數據庫和對象存儲。

knative是Google開源的serverless架構方案，旨在提供一套簡單易用的Serverless方案，把Serverless標準化。目前參與的公司主要是Google、Pivotal、IBM、Red Hat。knative是為了解決以容器為核心的serverless應用的構建、部署和運行的問題。knative是基于Kubernetes和Istio開發的，它使用Kubernetes來管理容器（deployment、pod），使用Istio來管理網絡路由（VirtualService、DestinationRule）。

目前serverless架構尚未完全成熟，云廠商依然在致力于基礎設施的封裝和屏蔽，同時云廠商也需要解決下列問題。

■ 性能問題，包括服務冷啟動帶來的延遲以及低性能問題、高并發函數實例擴縮容，大規模業務下函數實例的集群管理等。云服務提供商通常會降低那些不經常使用環境的資源，也會限制可用資源的總量，由此帶來響應延遲等低性能問題。

■ 開發者生態問題，Serverless架構在監控、debug調試、DevOps等方面的上下游支持還不完善；任何云計算工作事實上都會運行在一個公有云環境，而你無法控制或者進入這些云環境，導致監控、調試以及安全性都無法保障。