ECS上構建微服務架構

在構建微服務架構時面臨的一個主要問題就是，如果減輕執行、維護、擴充套件和管理微服務架構所需大規模分散式叢集資源的工作量和複雜性。目前主流的解決此問題的方案之一就是通過容器化部署和執行服務，降低運維和部署的複雜性。Amazon EC2 Container Service（ECS）是AWS提供的一個容器管理服務，能夠應對和解決微服務架構的部署和運維中面臨的種種挑戰。

本章節首先介紹Amazon ECS及其架構和工作原理，然後介紹利用Amazon ECS及其他相關AWS服務分層構建的一個高可用、高可擴充套件性、容錯的微服務，並討論該方案中涉及的分散式系統監控、服務發現、非同步通訊等問題。

Amazon ECS 簡介

什麼是Amazon ECS

Amazon ECS是一個高度可擴充套件伸縮、高效能容器管理服務，支援Docker容器[vi]並能夠讓你輕構地在EC2例項構建的叢集中執行應用程式。

Amazon ECS能夠讓你輕鬆地進行安裝、操作和擴充套件你的叢集資源。使用簡單的API呼叫，你就可以啟動和停止基於Docker的應用程式、查詢你的叢集狀態、還可以使用其他熟悉的服務，諸如安全組、ELB、EBS卷和AWS IAM角色。

Amazon ECS的特點

• 與Docker完美相容：支援 Docker 並使您能夠在 Amazon EC2 例項的叢集間執行和管理 Docker 容器。Amazon ECS 所管理的叢集中的每個 EC2 例項都執行有 Docker 守護程式，所以無論您將何應用程式打包為本地容器，它都將部署和執行在 Amazon ECS 上，無需進行任何配置更改。
• 內建叢集託管：管理自己的容器管理基礎設施通常涉及安裝、操作、擴充套件自己的叢集管理軟體、配置管理系統和監控解決方案。這些系統的可用性和可擴充套件性架構和管理很難。Amazon ECS 消除了容器管理工作的複雜性。使用 Amazon ECS，您只需要啟動容器例項叢集並指定想要執行的任務即可，所有叢集管理工作將由 Amazon ECS 完成。
• 程式設計控制：Amazon ECS 為您提供一組簡單的 API，方便您整合和擴充套件服務。使用 API，您可以建立和刪除叢集、註冊和取消註冊任務、啟動和終止 Docker 容器，並能提供叢集及其例項的狀態相關詳細資訊。您還可以使用 AWS CloudFormation[vii] 預置 Amazon ECS 叢集、註冊任務定義和安排容器。
• 任務排程：Amazon ECS  包含許多工排程程式和內建的Placement Engine，可以根據您的資源需求（例如 CPU 或 RAM）和可用性要求在叢集中放置容器。通過使用可用的任務排程程式，您可以安排長期執行的應用程式和服務以及批量作業。Amazon ECS API 還能提供完整的叢集狀態資訊，允許您編寫自己的任務排程程式或整合現有的第三方排程程式（例如 Marathon）。Amazon ECS 是共享狀態的樂觀併發系統，可以將叢集的完整狀態呈現給所有的計劃程式。通過使用 Amazon ECS API 或 Blox (一個用於容器管理和編排的開源物件集合)，您可以開發自己的任務排程程式或整合第三方排程程式。
• 負載均衡：Amazon ECS 已與 Application Load Balancing (ALB) 整合，支援您在多個容器之間分配流量。您只需指定任務定義和要使用的 ALB，Amazon ECS 服務計劃程式將自動新增和刪除 ALB 中的容器。您可以在任務定義中指定動態埠，這可為安排在 EC2 例項上的容器提供未使用的埠。您還可以使用基於路徑的路由與多個服務共享 ALB。
• 監控：Amazon ECS 為您的容器和叢集提供了監控功能。您可以監控正在執行的任務的 CPU 和記憶體使用率及總和，這些任務通過 Amazon CloudWatch 按任務定義、服務或叢集進行分組。您還可以設定 CloudWatch 警報，在您的容器或叢集需要擴大或縮小規模時提醒您。
• 日誌記錄：您可以將各個容器例項的 ECS 代理日誌和 Docker 容器日誌傳送到 Amazon CloudWatch 日誌，以簡化問題診斷。藉助 AWS CloudTrail，您還可以記錄所有的 Amazon ECS API 呼叫並將日誌檔案傳送給您。記錄的資訊包括 API 呼叫者的身份、API 呼叫的時間、API 呼叫者的源 IP 地址、請求引數以及 Amazon ECS 返回的響應元素。
• 安全性：Amazon ECS支援您為每項 ECS 任務指定一個 IAM 角色。如此一來，ECS 容器例項將獲得遵循“最低許可權”訪問策略的最小角色，允許您分別管理例項角色和任務角色。您還可以檢視哪項任務使用哪個角色，這些資訊均記錄在 CloudTrail 日誌中。

Amazon ECS的架構及工作原理

ECS的架構

ECS由以下主要元件構成：

• Task Scheduler：任務排程器負責將task和service以task definition檔案描述的形式按照一定的排程策略，放置到相應的Container Instance上進行執行。
• Resource Manager：Resource Manager負責對宿主機進行通訊，申請、釋放並管理任務執行時所需資源。
• ECS Cluster：ECS叢集是一組EC2例項的集合，由執行Docker容器的Container Instance（容器例項）組成，構成了ECS執行的整體資源。當執行任務時，ECS會根據task definition的資訊從ECR或者任何其他Docker映象倉庫中拉取對應的映象檔案，並在叢集中執行。
• Container Agent：Container Agent負責Container Instance與叢集的心跳通訊，負責訪問Container Instance、健康檢查、傳送命令等等。預設Container Agent是內建在 Amazon ECS-optimized AMI中的，當您建立Container Instance就已經自動安裝了Container Agent。
• Container Instance：Container Instance就是安裝了Container Agent並在ECS叢集上進行了註冊的EC2例項。當您執行ECS任務時，ECS會根據任務排程策略將任務放置到特定的Container Instance上執行。

圖3：ECS的架構

跨AZ保證高可用性

Amazon ECS通過跨可用區（AZ）執行應用程式容器來保證高可用性。您需要在VPC中建立您的ECS叢集，通過task definition（任務說明）和task service（服務說明）定義好Docker容器映象檔案，並其執行在您的ECS叢集上。此外，您還可以通過Amazon ECR，Docker Hub或任何私有映象倉庫來儲存和管理您的Docker容器映象檔案。

圖4：跨分割槽執行ECS叢集

靈活的任務排程

Amazon ECS將執行在容器中的作業分為兩種型別：task（任務）和service（服務）。

一個task通常指的是一次性的作業，比如定時觸發器、批量資料處理等，task 需要由一個task definition檔案定義其所需的資源和處理過程，並將它執行在您的叢集上。您可以指定執行在您的ECS叢集上的task個數。

一個service服務指的是永久執行在後臺的作業，您同樣需要在task definition檔案中對其進行定義。Amazon ECS允許您定義一定數量（由desired count引數指定）的任務程序來支援一個service，當某個任務程序失敗或者不健康，ECS會自動啟動新的任務程序，以保證該服務的任務數量達到desired count。

那麼如何將這些任務放到特定的容器例項上呢？Amazon ECS提供的Task Placement Engine支援多種容器任務排程策略:

• Binpacking：最少資源利用（根據CPU或者記憶體）的例項會優先被放置，這種策略會先將任務放到可用資源最少的例項上，減少了啟動過多的例項，提高了資源利用率。
• Spread：根據某個特定值進行平衡放置，這個特定值可以是一個鍵值對，也可以是instanceId或者host。一般可使用這種策略實現跨AZ的任務放置。
• Affinity：組合條件的放置策略，比如兩個符合條件的task不能同時放到某個例項中，或者兩個符合條件的task必須同時放到某個例項中。
• Distinct Instance：將每項任務放置在不同的容器例項中。

圖5：任務排程策略

此外，您可以任意組合多種排程策略，或者通過BLOX專案自定義您的任務排程策略。關於BLOX，詳見https://blox.github.io/。

分層構建微服務方案

本節我們通過分散式應用中經典的CDN層、API層、應用層以及資料持久層分層介紹使用AWS ECS及其他AWS服務構建一個高效能、高可用的微服務。

圖6：分層構建微服務

CDN層

CDN層的意義在於加速靜態和動態資源的傳輸，並潛在地減輕後端伺服器的壓力。

使用CDN，可以讓您的微服務應用客戶端從最近的端點或者代理伺服器、快取伺服器上獲取資源，或者可以讓您通往原資料伺服器的鏈路得到優化，從而降低延時， 加快您網站及應用上的圖片、視訊、指令碼等資料的傳輸。

API層

API層是所有請求的入口，它可以隱藏應用程式的業務邏輯細節，通過諸如HTTP REST API接受外部請求。API層一般還需要對所接收的請求進行流量管理、請求過濾、快取及訪問授權和控制。您可以使用Application Load Balancer（ALB）來實現您的API層。ALB是 Amazon Elastic Load Balancing（ELB） 服務的一個負載均衡選項，支援您在運行於一個或多個 EC2例項上的多個服務或容器之間基於內容定義路由規則。它可以做到：

• 基於主機的路由：您可以基於 HTTP 標頭的“主機”欄位路由客戶端請求，以便您從同一個負載均衡器路由到多個域。
• 基於路徑的路由：您可以基於 HTTP 標頭的 URL 路徑路由客戶端請求。

ALB提供了對容器化應用程式的支援，您可以對應用程式負載均衡器進行配置，以在單個 EC2 例項的多個埠之間對容器進行負載均衡。藉助 Amazon EC2 Container Service (ECS)，您可以在 ECS 任務定義中指定一個動態埠，以便在將容器安排到 EC2 例項上時為其提供一個未使用的埠。ECS 計劃程式會自動使用該埠將任務新增到 ALB Target Group。

圖7：使用ALB實現API層作為服務呼叫入口

應用層

應用層實現了具體的應用程式業務邏輯。AWS提供了多種方式來執行應用程式，您可以將程式直接部署到EC2上、或者使用Elastic Beanstalk服務快速構建執行環境，或者使用無伺服器服務AWS Lambda、當然也可以使用容器管理服務ECS。這裡介紹ECS利用容器技術執行應用層的好處。

• 一致性：容器映象檔案具有一致性，無論您將同一個容器映象部署到開發者的筆記本還是測試環境，抑或是生產環境，容器都會保持一致的工作。
• 靈活性：容器技術將應用程式劃分為各個獨立的、鬆耦合的服務，這一點跟微服務架構思想是完美融合的。容器可以使微服務架構的靈活性得到更好的表現。
• 高資源利用率：容器允許您預先定義需要使用的資源資料（比如CPU和記憶體），可以在多個下層宿主機構成的叢集上共享資源，達到比虛擬機器技術更好的資源利用率。
• 高工作效率：容器具有一致性、版本公開性、鬆耦合和可輕鬆回滾等特性的可以重複使用的工作集。您不需要重複“造輪子”，無論從開發和運維上都可以提高您的工作效率。

資料持久層

資料持久層負責將業務中使用到的資料進行儲存和管理。將資料管理和持久化單獨封裝一層，可以讓應用層實現無狀態化，從而便於應用層進行水平伸縮擴充套件和實現容錯機制。

靜態資料一般可以儲存在AWS Simple Storage Service（S3）服務上，並通過AWS CloudFront進行分發。關於S3，可以參考 https://www.amazonaws.cn/s3/

會話資料和常用的資料，可以儲存在資料快取中介軟體中，比如Memcached或者Redis。AWS提供了ElasticCache服務管理這兩種快取服務。關於ElasticCache，可以參考 https://www.amazonaws.cn/elasticache/

對一致性要求較高的業務資料可以儲存在關係型資料庫中，AWS Relational Database Service（RDS）服務可以管理六大常見關係型資料庫引擎（Microsoft SQL Serve,Oracle,MySQL,MariaDB,PostgreSQL, Amazon Aurora）。關於RDS，可以參考 https://www.amazonaws.cn/rds/

關係型資料庫不利於伸縮和業務擴充套件，利用NoSQL資料庫得到了更好的可擴充套件性、可用性和效能。您可以使用Amazon DynamoDB建立可以儲存任意資料、應對大量訪問的資料庫表。DynamoDB可以將表中資料分佈到足夠多的伺服器上，以滿足高效能、大資料量、大訪問量的儲存要求。關於DynamoDB，可以參考https://www.amazonaws.cn/dynamodb/

解決微服務架構中的常見問題

在討論如何分層構建微服務後，通過ECS和AWS相關服務，我們已經很大程式上減輕了架構和運維微服務應用所需的工作量。本節我們將討微服務架構中另外幾個常見的問題，並結合AWS提供的相關服務對這些問題進行分析和處理。

服務發現

如何讓服務發現彼此並進行互動，這是微服務架構必須解決的問題。服務發現包括檢查服務的健康狀態以及自動發現新服務上線。在AWS中提供了幾種方式來實現服務發現：

1. 基於 Application Load Balancer實現的服務發現

ALB具有健康檢查和服務上線註冊下線登出的功能，將這些功能與DNS解析服務相結合，可以低成本地輕鬆解決服務發現問題。

您可以給每個微服務設定自定義的域名，然後通過一個CNAME入口，將這些服務繫結到某個Elastic Load Balancer的DNS下。這些服務的DNS名將會被髮布給所有需要訪問服務的應用程式, 同時結合ALB基於路徑路由的功能，能夠利用Target Group和Path的結合分發給不同的微服務，節省資源和成本。

圖8：基於Elastic Load Balancer的服務發現

2. 基於Key-Value對儲存的服務發現

您還可以使用Key-Value鍵值對儲存的形式來實現服務發現，雖然這種方式實現起來需要您花費比其他方式更多的時間，但是它能提供更好的靈活性和擴充套件性，並且不用擔心DNS快取問題。這種方式天生與客戶端負載均衡技術相吻合，客戶端負載均衡可以解決效能瓶頸並簡化流量管理。

圖9展示的是一個利用Amazon DynamoDB作為Key-Value鍵值儲存，並結合DynamoDB Stream以生產者消費者模式來實現服務狀態更改通知的架構。

圖9：基於Key-Value對儲存的服務發現

3. 基於第三方開源元件的服務發現

您還可以使用開源社群中的服務發現元件來構建服務發現，例如Hadoop的子專案ZooKeeper或者Hashicorp公司的Consul[vii], 這種方式的好處在於合理利用了已有的開源社群中的優秀框架來提供基於Key-Value的特定服務，並且這些開源社群的元件對AWS的整合也非常對友好，能夠非常快速的搭建服務發現的方案。下圖10展示了Consul與ECS的協同工作, 宿主機將會首先利用Registrator[ix]的Agent在Docker啟動時將Consul Agent註冊到Consul Server，由於Consul基於訊息訂閱的模型設計，所以其他服務很快收到訂閱知道新的元件上線並且能夠通過其API瞭解到其他服務的狀態.

圖10：基於Consul服務發現

資料一致性

單體型架構的應用一般都是將資料儲存在一個數據庫中，應用程式中所有模組統一使用一致的資料模型。微服務則不能使用這些中心資料庫，因為這與微服務去中心化、要求獨立型的原則不符。每一個微服務元件都可以擁有自己的一套資料持久化方案。那麼如何在服務通訊過程中，保持資料的一致性呢？

通常情況下，微服務中狀態的變化將會影響整個系統資料的一致性。在這種情況下，事件驅動模型被實踐證明可以用於實現資料的最終一致性。事件驅動模型的核心就是將應用程式每一次狀態變化當作一個事件記錄下來，與持久化資料狀態不同，資料是通過一連串事件流儲存起來的。資料庫事務日誌和版本控制就是應用事件驅動模型最出名的兩個例子。

在微服務場景中，事件驅動模型以“訂閱者-消費者”形式進行應用程式各服務間的解耦，在各個應用不同資料系統的微服務元件之間共享事件流資料，事件驅動模型還可用於讀寫分離場景，提升讀和寫的效能。

下圖展示如何利用AWS Kinesis Stream作為中心事件流，捕獲各個服務的資料變化作為事件，並將事件流記錄在S3上。圖中各個微服務元件由ALB、ECS和RDS組成，如圖所示，微服務元件Microservice 1由於某個狀態改變，向Kinesis釋出事件，Kinesis將事件持久化到S3中（客戶可以使用Redshift服務對這些事件流進行分析），其他微服務元件如Microservice 2和3訂閱了這個事件，會拉取並過濾事件，並在本服務元件中進行相應的處理。通過這種機制，可以實現不同資料系統間資料的最終一致。

圖11：Kinesis實現事件驅動

非同步通訊

在單體型架構的應用中，各個模組間的通訊是非常簡單的，可以是簡單的方法呼叫或者通過內部事件釋出機制。而當使用微服務架構時，服務間的通訊必須通過網路遠端呼叫。

常用的微服務通訊機器除了HTTP REST API進行API呼叫外，對於一些對實時性要求不高，又耗時較長的通訊場景，經常需要使用到訊息佇列實現非同步通訊。Amazon Simple Queue Service（SQS）和Amazon Simple Notification Service（SNS）都是AWS提供的用於非同步通訊、通知推送的服務。

服務監控與日誌記錄

在微服務架構中，您需要對各個服務進行監控，以判斷服務是否健康，是否可用。您還需要對服務的API呼叫記錄、訪問記錄等日誌進行記錄，以實現問題發現和追蹤。

您可以使用Amazon CloudWatch來收集系統指標，集中管理和監控日誌檔案，設定預警並自動適應您的執行環境中發生的變化。Amazon CloudWatch可以監控的AWS資源包括EC2例項、DynamoDB表和RDS DB例項，也可以監控任何您的應用和服務生成的自定義指標和日誌檔案。

1. 監控

利用Amazon CloudWatch，您可以輕鬆地對微服務元件進行監控，可以監控整個系統的資源利用率、應用程式的效能和服務的健康狀態。CloudWatch非常簡單，只要進行一些簡單的設定，您就可以擁有一套可靠、可伸縮、靈活的監控方案。您不再需要自己去維護一個複雜的監控系統。在微服務架構中運用CloudWatch的另一個好處就是，CloudWatch提供的自定義收集指標可以讓開發人員針對特定服務定製特定指標。另外，基於收集到的自定義指標，自動伸縮也可以得到輕鬆地實現。

2. 記錄日誌

持續記錄日誌對於排查和發現問題起到非常重要的作用。微服務讓產生的更新發布頻率比以往傳統架構更多，並鼓勵工程師團隊更多地嘗試新的功能和特性。瞭解使用者的影響對整個應用的逐步提升起來決定性的作用。
為了更好地除錯和總覽整個分散式系統的狀況，我們必需將日誌儲存在一個統一的中心。在AWS中，您可以使用Amazon CloudWatch Logs來監控、儲存和訪問您EC2例項上、CloudTrail或者其他資源上的日誌檔案。

3. 集中管理日誌

您可以有很多不同的選擇來集中管理日誌檔案。大部分AWS服務已經“開箱即用”地集中了日誌檔案。在AWS中，首要的存放日誌檔案的地方就是Amazon S3和Amazon CloudWatch Logs。圖13展示的是一些AWS服務的日誌記錄能力。日誌檔案對於每個系統來說都是重要的部分，基本每一個系統操作都會生成一條日誌記錄。中心化的日誌管理方案就是將所有日誌檔案放在一個統一的中心位置，這樣便於日誌的訪問、查詢和分析。

圖12：AWS部分服務的日誌記錄能力

4. Correlation IDs（關聯ID）

在很多場景中，一個請求需要由多個微服務共同合作進行處理。想象一下，一個由數十個微服務組成的複雜的系統，當服務鏈中某個服務出現一個錯誤時的對整個服務鏈所造成的影響有多大。即使每一個微服務都有進行很好的日誌記錄，並集中化日誌管理，要追蹤出現的錯誤，需要將所有這些跟這個錯誤關聯的日誌都找出來，這是非常困難的。

關聯ID的中心思想就是，當負責面向使用者的服務收到請求時建立一個特定的ID。這個ID可以放在HTTP頭（比如，使用類似“x-correlation-id”這個的頭欄位）然後在服務鏈中傳遞到其他服務中去。這個ID就可以在各個服務獨立的日誌中記錄，這樣針對特定請求，就可以根據這個關聯ID將所有關聯的日誌記錄都找出來了。

為了得到日誌檔案中正確的服務呼叫順序，可以在HTTP頭中傳遞一個計數器，每經過一個服務就累加一次。

審計

在微服務架構中需要處理的另一個挑戰，就是潛在的數百個分散式服務如何既確保所有使用者操作的可見性，又能夠在組織層面獲得良好的整體感觀。為了加強安全管理，對資源訪問和引起系統變化的操作進行審計就顯得非常重要。對系統的更改無論在獨個服務中，還是在跨服務的整個系統層面，都必須進行嚴格追蹤記錄。在微服務架構中，更改是經常需要發生的，這也就讓對更改的審計變得更加重要。

1. 審計追蹤

AWS CloudTrail是一個非常有用的在微服務中追蹤更改的工具，因為它能將所有在AWS平臺上的API呼叫進行記錄，並實時傳送到CloudWatch Logs或者幾分鐘內傳送到Amazon S3中。它可以記錄從AWS Management Console、AWS CLI、SDK發起或者直接呼叫的記錄。

所有使用者的行為和自動化執行的系統行為都變成可以查詢和分析的。CloudTrail記錄的資訊包括使用者賬號、時間戳、呼叫的目標服務、呼叫者的IP地址、請求引數和返回響應元素。

2. 事件和實時操作

整個系統結構中有一些系統狀態的變化是必須對其進行快速響應的，必須快速進行修復或者必須及時跟進處理這些變化。Amazon CloudWatch Events實現了一個近實時的事件系統。它可以宣告一些適配某些系統狀態變化的規則，並定義好自動響應這些變化的措施。

Amazon CloudWatch Events與CloudTrail結合，可以為所有AWS服務上的所有API呼叫生成事件。它還支援自定義事件或者根據某個特定的排程策略生成事件（比如定時事件）。當一個事件發生並且符合您系統中定義的規則時，CloudWatch Events將立即通知您預先定義好的系統中的某個角色或人物，以便他們及時做出響應措施。更好的做法是，當事件觸發時，您可以定義自動化處理的工作流或者呼叫一個自定義的Lambda function。

圖13展示的是使用CloudTrail和CloudWatch Events處理在一個微服務架構系統中進行審計和系統修復的需求。所有的微服務都由CloudTrail進行追蹤、審計並將審計資訊儲存在S3 bucket中。當一個對您系統的更改發生時，CloudWatch Events能在CloudTrail基礎上觸發事件警告，及時通知系統管理員。您還可以對所有這些日誌資訊使用Elasticsearch等搜尋引擎技術進行日誌查詢。

圖13：審計追蹤和系統修復

總結

微服務架構可以突破傳統單體型架構遇到的種種限制，它是鬆耦合的，去中心化的，黑盒的，多語種的，在可用性、可靠性、可伸縮性、可擴充套件性、安全性、效能和工作效率上更加優秀。但微服務架構也面臨著像資源管理、服務發現、訊息通訊、資料一致性等諸多問題和挑戰，利用AWS提供的ECS及其他相關服務，可以解決微服務架構面臨的挑戰和難題，輕鬆架構微服務應用，更好地擁抱微服務帶來的種種便利。

客戶案例

Remind

Remind 是一款 Web 和移動應用程式，教師可以使用該應用程式向學生髮送簡訊並與家長保持聯絡。Remind 在自己的平臺上擁有 2500 萬名使用者和 150 多萬名教師，該應用程式每月可傳送 1.5 億條訊息。

“遷移到 Amazon ECS 後，我們服務的效能得到了顯著提升。我們將服務響應時間的第 99 個百分位降低了 50%。” – Jason Fischl 工程師副總裁

Coursera

Coursera 是一家教育技術公司，致力於在全球範圍內提供世界上最好的課程。該公司與世界各地的頂尖大學和機構合作，為所有人免費提供各種線上課程。Coursera 擁有來自 190 個國家/地區的 1300 多萬用戶，提供來自 119 個機構的 1000 多個課程，涵蓋從 Python 程式設計到作曲的各個主題。

“藉助 Amazon ECS，Coursera 可以集中精力釋出新軟體，無需花時間管理群集。” – Frank Chen軟體工程師

Shippable

Shippable 是一個提供託管式持續整合、測試和使用 GitHub 和 Bitbucket 等儲存庫進行部署的平臺。該公司在從應用程式建立一直到向終端使用者交付軟體的整個過程中為開發人員和運營團隊提供幫助，並在整個過程中實現完全的自動化和完全的控制。Shippable 的平臺有助於消除實現重複性持續整合/持續交付和工作流中的阻礙和難題，這樣，開發人員便能夠專注於交付高質量程式碼。

“藉助 Amazon ECS，我們的開發人員幾乎不用花時間在運營相關工作上。過去，我們的高階開發人員需要將 80% 的時間花費在後端基礎設施管理功能方面，而現在則將 80% 的時間投入在客戶功能上。” – Avi Cavale執行長兼聯合創始人

Segment

Segment 為企業提供一種可從樞紐中心收集客戶資料，以備日後用於分析、市場營銷和其他用途的服務。該公司的總部位於舊金山，擁有廣泛的客戶群，從初創公司到大型企業，其中包括 Nokia、Angie’s List、Conde Nast、The Motley Fool 和 Salesforce Foundation 等。

“轉而使用 Amazon ECS 大大簡化了服務的執行，無需擔心預配置或可用性。”- Calvin French-Owen聯合創始人兼首席技術官

mytaxi

mytaxi 基於 AWS 設計了一款採用速度快且可輕鬆擴充套件的 Docker 容器的微服務架構，以應對新年除夕等特別日子的需求高峰。該公司執行著歐洲領先的計程車應用程式，此應用程式在 40 個城市中將 1000 萬用戶與 45000 輛計程車聯絡起來。整個基礎設施都構建在 AWS 之上，其中的 Amazon EC2 和 Amazon ECS 等服務可為 mytaxi 的 Docker 容器提供支援。

“2015 年 11 月，我們將 Docker 容器架構移動到了 Amazon ECS，而在 12 月，我們有史以來第一次能夠慶祝新年，因為我們的系統可以處理大量請求，並且沒有發生任何崩潰或中斷，我們對這項成就感到極為自豪。”- Sebastian Herzberg系統工程師

Burda Studios

BurdaStudios 是全球媒體集團 Hubert Burda Media 的一個部門，擁有近 10000 名員工和 500 多個品牌，包括家庭和生活方式類雜誌以及企業間出版物。BurdaStudios 專門從事影視製作和數字出版。該公司的旗艦網站是 Bunte.de，一個在德語歐洲國家/地區 (德國、瑞士和奧地利) 處於領先地位的名人八卦門戶。該網站是瞭解好萊塢演員、體育明星和皇室成員最新新聞的首選網站。它吸引了 600 萬獨立使用者，月訪問量高達 3000 – 3500 萬次 (其獨立使用者的數量比最大競爭對手高出約 20%)，通過展示、視訊和本地廣告盈利。

“我們通過 AWS 和微服務架構所做的事情正是數字出版業的未來。”- Hansjörg Posch BurdaStudios 首席技術官

Airtime

使用 AWS 服務重新設計其應用程式之後，Airtime 能夠以更加快速可靠的方式為客戶提供社交體驗，而且不會產生任何延遲。Airtime 是一家社交媒體公司，也是一款移動應用程式，可讓使用者在 iOS 和 Android 裝置上實時分享自己喜愛的音樂、視訊，並進行訊息收發。該公司通過使用 Amazon EC2、Amazon Route 53 和 Amazon S3 等基本服務開始了採用 AWS 的過程，然後重新設計了自己的平臺，以便能在採用 Amazon EC2 Container Service (Amazon ECS) 和 Docker 容器的微服務架構上執行。除了改善客戶體驗之外，Airtime 還通過滾動部署簡化了內部流程，而且可以利用 Elastic Load Balancing Connection Draining 等較新的 AWS 功能。

Abema TV

AbemaTV 是一家網際網路媒體服務公司，運營著日本領先的流媒體平臺之一 – FRESH!by AbemaTV。目前， FRESH! by AbemaTV 可提供大約 1400 個頻道和將近 37000 個節目：從廣播電臺的流媒體服務到由 CyberAgent (AbemaTV 的母公司) 開發的原版影視劇，應有盡有。AbemaTV 使用 Amazon Aurora 資料儲存來執行其寫入密集型微服務 (例如時間表和聊天)，並利用 Amazon Relational Database Service (Amazon RDS) 上的 MySQL 資料庫來處理剩餘的微服務 API。所有 API 都通過 Amazon CloudFront 和 Amazon API Gateway 進行管理。對於可能會影響 API 響應時間的流程，AbemaTV 實施了一套可通過 Amazon Simple Queue Service (Amazon SQS) 佇列接收任務的工作程式。

“Amazon EC2 Container Service 對於我們構建具有高可用性、穩定性的微服務，以及受益於各種 AWS 服務而言至關重要。”- Akinori Yamada 工程團隊

Linden Lab

Linden Lab 是一家總部位於舊金山的網際網路公司，因推出 Second Life 虛擬世界而廣為人知。Second Life 為使用者提供了一個可生成 3D 內容並與之進行互動的平臺。使用者可通過 Linden Lab 的客戶端程式或通過可選的第三方檢視器訪問 Second Life 虛擬世界。該公司的其他產品包括 Blocksworld，它讓使用者可以構建虛擬 3D 塊並使用這些 3D 塊進行遊戲；還包括“Project Sansar”，這是計劃於 2016 年釋出的用於提供虛擬體驗的新平臺程式碼名稱。

“使用 Amazon EC2 Container Service，我們可以切實地提高開發速度，從而將構建和部署時間縮短 50% 或更高。藉助 Amazon ECS，我們擁有了一個非常穩定的平臺，這讓我們可以大幅擴充套件產品規模。” – Landon McDowell 運營副總裁

CyberAgent

CyberAgent 是一家網際網路媒體服務公司，運營著日本領先的流媒體平臺之一 – FRESH!。目前，FRESH! 可提供大約 1400 個頻道和將近 37000 個節目，從廣播電臺的流媒體服務到原版影視劇，應有盡有。CyberAgent 使用 Amazon Aurora 資料儲存來執行其寫入密集型微服務 (例如時間安排和對話)，並利用 Amazon Relational Database Service (Amazon RDS) 上的 MySQL 資料庫來處理其餘的微服務 API。所有 API 都通過 Amazon CloudFront 和 Amazon API Gateway 進行管理。對於可能會影響 API 響應時間的流程，CyberAgent 實施了一套可通過 Amazon Simple Queue Service (Amazon SQS) 佇列接收任務的工作程式。

“Amazon EC2 Container Service 對於我們構建具有高可用性、穩定性的微服務，以及受益於各種 AWS 服務而言至關重要。” – Akinori Yamada 工程團隊

Meteor Development Group

Meteor Development Group 是一款開源的跨平臺 JavaScript 應用程式平臺，開發人員可以使用它為 Web、Android 和 iOS 應用程式編寫程式碼。Meteor 由總部位於舊金山的 Meteor Development Group 建立，使用分散式資料協議和釋出-訂閱模式自動將更改傳送給客戶，無需開發人員編寫同步程式碼。Meteor 是 GitHub 上領先的 Web 應用程式框架，每天有數以千計的公司要依靠該平臺構建現代化應用程式。

“AWS 的穩定性大家有目共睹。我們面臨的難題是：‘我們能夠擴充套件執行所有客戶應用程式所需的計算資源數量嗎？’以及，“我們能夠擴充套件協調所有這些資源的機制嗎？”使用 AWS，我們可以對這兩個問題回答‘能’。” – Matt DeBergalis 聯合創始人兼產品副總裁

引用

[vi] https://www.docker.com

[vii] https://aws.amazon.com/cloudformation/

[viii] https://www.consul.io/

[ix]http://gliderlabs.github.io/registrator/latest/

作者介紹

李磊，AWS解決方案架構師，負責基於AWS的雲端計算方案的架構設計，同時致力於AWS雲服務在國內和全球的應用和推廣。在大規模併發後臺架構，電商系統，社交網路平臺、網際網路領域應用，DevOps以及Serverless無伺服器架構等領域有著廣泛的設計與實踐經驗。在加入AWS之前超過十年的開發和架構設計經驗, 帶領團隊攻克各種技術挑戰，總是希望站在技術的最前沿。