在本文中，我們簡要總結了微服務的共同特征，討論了構建微服務的主要挑戰(zhàn)，并描述了產(chǎn)品團隊如何利用AWS來克服這些挑戰(zhàn)。

微服務是一種架構和組織的軟件開發(fā)方法，用于加快部署周期、促進創(chuàng)新、提高軟件應用程序的可維護性和可伸縮性。因此，軟件被組合成小型獨立服務，這些服務通過定義良好的api進行通信，并由小型自包含團隊擁有。

“微服務”一詞在過去幾年中受到越來越多的關注。微服務體系結構并不是一種全新的軟件工程方法，而是各種成功和成熟概念的集合和組合，如面向?qū)ο蠓椒?、敏捷軟件開發(fā)、面向服務體系結構、API優(yōu)先設計和持續(xù)交付。

鑒于微服務這個術語是一個總括性術語，很難給出一個精確的定義。然而，所有的微服務架構都有一些共同的特點：

• 分散式：微服務架構是具有分散式數(shù)據(jù)管理的分布式系統(tǒng)。他們不依賴中央數(shù)據(jù)庫中的統(tǒng)一模式。每個微服務在數(shù)據(jù)模型上都有其自己的視圖。這些系統(tǒng)還以開發(fā)，部署，管理和操作的方式分散。

• 獨立的：微服務架構中的不同組件可以獨立更改，升級或替換，而不會影響其他組件的功能。同樣，負責不同微服務的團隊可以相互獨立行動。

• 做好一件事情：每個組件都是圍繞一組功能而設計的，并且側重于特定領域。一旦組件達到一定的復雜度，它可能會成為自己的微服務的候選者。

• Polyglot：微服務架構沒有遵循“一刀切”的方法。團隊可以自由選擇適合其特定問題的最佳平臺。結果，微服務架構通常在操作系統(tǒng)，編程語言，數(shù)據(jù)存儲和工具方面是異構的，這種方法稱為多語言持久性和編程。

• 黑匣子：微服務的各個組件被設計為一個黑匣子，即它們將復雜性的細節(jié)從其他組件隱藏起來。服務之間的任何通信都是通過定義明確的API進行的。通常，它們避免任何會損害組件獨立性的隱藏通信，例如共享庫或數(shù)據(jù)。

• 構建，運行它：通常，負責構建服務的團隊還負責生產(chǎn)中的操作和維護-此原理也稱為DevOps。團隊不僅可以按照自己的進度獨立進步，而且還有助于使開發(fā)人員與軟件的實際用戶緊密聯(lián)系，并增進對客戶需求和期望的理解。微服務的組織方面不應該被低估，因為根據(jù)康韋定律，系統(tǒng)設計在很大程度上受到構建系統(tǒng)團隊的組織結構的影響。

微服務的好處

微服務的分布式特性培養(yǎng)了一個由小型獨立團隊組成的組織，這些團隊負責他們的服務。它們能夠獨立地開發(fā)和部署，并與其他團隊并行，從而加快開發(fā)和部署過程。代碼庫團隊正在處理的復雜度降低了，依賴項的數(shù)量減少了，從而使代碼沖突最小化，方便了更改，縮短了測試周期，并最終縮短了新特性和服務的上市時間。來自客戶的反饋可以更快地集成到即將發(fā)布的版本中。

事實上，小團隊可以自主行動，并為各自的問題領域選擇適當?shù)募夹g、框架和工具，這是創(chuàng)新的重要驅(qū)動力。責任和問責培養(yǎng)了服務的主人翁文化。

通過在同一組中合并開發(fā)和操作技能來建立DevOps文化，可以消除可能的摩擦和相互矛盾的目標。當涉及到部署時，敏捷過程不再停止。相反，從提交到發(fā)布代碼的整個應用程序生命周期管理過程可以自動化。嘗試新的想法變得很容易，如果有什么東西不起作用，就可以回過頭來。失敗的低成本創(chuàng)造了一種變革和創(chuàng)新的文化。

圍繞微服務組織軟件工程也可以提高代碼的質(zhì)量。將軟件劃分為定義良好的小模塊的好處類似于面向?qū)ο筌浖こ痰暮锰帲禾岣吡舜a的可重用性、可組合性和可維護性。

細粒度解耦是構建大規(guī)模系統(tǒng)的最佳實踐。這是性能優(yōu)化的先決條件，因為它允許為特定的服務選擇合適的最佳技術。每個服務都可以使用適當?shù)木幊陶Z言和框架實現(xiàn)，利用最佳的數(shù)據(jù)持久性解決方案，并使用性能最佳的服務配置進行微調(diào)。適當解耦的服務可以水平擴展并且相互獨立。垂直擴展，即在更大的機器上運行相同的軟件，受到單個服務器容量的限制，在擴展過程中可能會導致停機。水平擴展（即向現(xiàn)有池中添加更多服務器）是高度動態(tài)的，不會受到單個服務器的限制?？s放過程可以完全自動化。此外，應用程序的彈性可以得到提高，因為故障組件可以很容易地自動更換。

微服務架構也使得實現(xiàn)故障隔離變得更容易。諸如健康檢查、緩存、隔板或斷路器之類的技術允許減少故障組件的爆炸半徑，并提高給定應用程序的總體可用性。

基于AWS的簡單微服務體系結構

上圖顯示了AWS上典型微服務的參考體系結構。該體系結構分為四層：內(nèi)容交付層、API層、應用層和持久層。

內(nèi)容交付層的目的是加速靜態(tài)和動態(tài)內(nèi)容的交付，并可能卸載API層的后端服務器。由于微服務的客戶端是從最近的邊緣位置提供服務的，并且可以從緩存或代理服務器獲得響應，并優(yōu)化到源服務器的連接，因此可以顯著減少延遲。相互靠近運行的微服務不會從CDN中受益，但可能會實現(xiàn)其他緩存機制以減少聊天次數(shù)并最小化延遲。

API層是所有客戶機請求的中心入口點，它將應用程序邏輯隱藏在一組編程接口（通常是httprestapi）后面。API層負責接受和處理來自客戶端的調(diào)用，并可能實現(xiàn)諸如流量管理、請求過濾、路由、緩存或身份驗證和授權等功能。許多AWS客戶使用Amazon彈性負載平衡（ELB）和Amazon彈性計算云（EC2）以及自動伸縮來實現(xiàn)API層。

應用層實現(xiàn)實際的應用邏輯。與API層類似，它可以使用ELB、Auto Scaling和EC2實現(xiàn)。

持久性層集中了使數(shù)據(jù)持久化所需的功能。將此功能封裝在一個單獨的層中有助于將狀態(tài)排除在應用程序?qū)又?，并更容易實現(xiàn)應用程序?qū)拥乃綌U展和容錯。靜態(tài)內(nèi)容通常存儲在amazons3上，由amazoncloudfront交付。常用的會話數(shù)據(jù)存儲在內(nèi)存緩存中，如Memcached或Redis。AWS提供這兩種技術作為托管Amazon ElastiCache服務的一部分。在應用程序服務器和數(shù)據(jù)庫之間放置緩存是一種常見的機制，可以減輕數(shù)據(jù)庫的讀取負載，從而允許使用資源來支持更多的寫入。緩存還可以改善延遲。

關系數(shù)據(jù)庫在存儲結構化數(shù)據(jù)和業(yè)務對象方面仍然非常流行。AWS提供了六個數(shù)據(jù)庫引擎（microsoftsqlserver、Oracle、MySQL、MariaDB、PostgreSQL和amazonaurora）作為托管服務。

圖2顯示了微服務的體系結構，其中所有層都是由托管服務構建的，這消除了為實現(xiàn)可擴展性和高可用性而進行設計的體系結構負擔，并消除了運行和監(jiān)視微服務底層基礎結構的操作工作。

降低復雜性

上面的架構已經(jīng)高度自動化了。盡管如此，仍有空間進一步減少運行、維護和監(jiān)控所需的操作工作。

構建、持續(xù)改進、部署、監(jiān)視和維護API層可能是一項耗時的任務。有時需要運行不同版本的api，以確?？蛻舳怂衋pi的向后兼容性。開發(fā)周期中的不同階段（如開發(fā)、測試、生產(chǎn)）進一步增加了操作工作。

訪問授權是所有api的一個關鍵特性，但構建起來通常很復雜，而且常常是重復性的工作。當一個API發(fā)布并獲得成功后，下一個挑戰(zhàn)就是管理、監(jiān)控和利用API的第三方開發(fā)人員的生態(tài)系統(tǒng)。

其他重要的特性和挑戰(zhàn)包括限制請求以保護后端、緩存API響應、請求和響應轉換，或者使用Swagger等工具生成API定義和文檔。

amazonapi網(wǎng)關解決了這些挑戰(zhàn)，降低了API層的操作復雜性。amazonapigateway允許客戶通過導入Swagger定義或在AWS管理控制臺中單擊幾下，以編程方式創(chuàng)建API。API網(wǎng)關充當運行在Amazon EC2、Amazon ECS、AWS Lambda或任何本地環(huán)境上的任何web應用程序的前門。簡而言之：它允許在不管理服務器的情況下運行api。圖2顯示了API網(wǎng)關如何處理API調(diào)用以及如何與其他組件交互。來自移動設備、網(wǎng)站或其他后端服務的請求被路由到最近的Amazon CloudFront PoP，以最小化延遲并提供最佳的用戶體驗。API網(wǎng)關首先檢查請求是否在緩存中，如果沒有可用的緩存記錄，則將其轉發(fā)到后端進行處理。一旦后端處理了請求，API調(diào)用度量就會記錄在amazoncloudwatch中，內(nèi)容就會返回給客戶端。

與運行ELB/Autoscaling/EC2相比，AWS提供了幾個選項來簡化部署，并進一步降低維護和運行應用程序服務的操作復雜性。一種選擇是使用彈性豆莖。Elastic Beanstalk背后的主要思想是，開發(fā)人員可以輕松地上傳他們的代碼，并讓Elastic Beanstalk自動處理基礎設施供應和代碼部署。重要的基礎設施特性（如自動擴展、負載平衡或監(jiān)視）是服務的一部分。

AWS Elastic Beanstalk支持多種編程框架，如Java、.Net、PHP、，節(jié)點.js，Python、Ruby、Go和Docker，以及熟悉的web服務器，如Apache、Nginx、Phusion Passenger和IIS。

另一種減少部署操作工作量的方法是基于容器的部署。像Docker這樣的容器技術在過去的幾年里得到了廣泛的應用。這得益于以下幾個好處：

• 靈活性：容器化鼓勵將應用程序分解為獨立的細粒度組件，這使其非常適合微服務體系結構。

• 效率：容器允許對資源需求（CPU，RAM）進行明確規(guī)定，從而可以輕松地在基礎主機之間分布容器并顯著提高資源利用率。與虛擬服務器相比，容器的性能開銷也很輕，并且可以在底層操作系統(tǒng)上有效共享資源

• 速度：容器是定義明確且可重復使用的工作單元，具有不變性，顯式版本控制和易于回滾，精細的粒度和隔離等特性，所有這些特性均有助于顯著提高開發(fā)人員的生產(chǎn)率和運營效率。

amazonecs無需安裝、操作和擴展自己的集群管理基礎設施。通過簡單的API調(diào)用，您可以啟動和停止支持Docker的應用程序，查詢集群的完整狀態(tài)，并訪問許多熟悉的功能，如安全組、彈性負載平衡、EBS卷和IAM角色。

無服務器計算

消除操作復雜性的最終方法就是不再使用服務器。客戶只需上傳他們的代碼，讓AWS Lambda處理運行所需的一切，并以高可用性擴展執(zhí)行。Lambda支持多種編程語言，可以從其他AWS服務觸發(fā)，也可以直接從任何web或移動應用程序調(diào)用。Lambda與amazonapi網(wǎng)關高度集成。從amazonapi網(wǎng)關到AWS Lambda進行同步調(diào)用的可能性允許創(chuàng)建完全無服務器的應用程序。

雖然關系數(shù)據(jù)庫仍然非常流行，而且人們對它的理解也很透徹，但它們并不是為無限規(guī)模而設計的，這會使應用技術來支持大量查詢變得非常困難和耗時。NoSQL數(shù)據(jù)庫被設計成支持可伸縮性、性能和可用性而不是關系數(shù)據(jù)庫的一致性。一個重要的因素是NoSQL數(shù)據(jù)庫通常不強制執(zhí)行嚴格的模式。數(shù)據(jù)分布在可以水平縮放的分區(qū)上，并通過分區(qū)鍵檢索。

由于單個微服務的設計目的是做好一件事，因此它們通常有一個簡化的數(shù)據(jù)模型，非常適合NoSQL持久性。您可以使用amazondynamiodb創(chuàng)建一個數(shù)據(jù)庫表，該表可以存儲和檢索任意數(shù)量的數(shù)據(jù)，并提供任意級別的請求通信。amazondynamiodb自動將表的數(shù)據(jù)和通信量分布在足夠多的服務器上，以處理客戶指定的請求容量和存儲的數(shù)據(jù)量，同時保持一致和快速的性能。

為無服務器體系結構協(xié)調(diào)部署可能是一項具有挑戰(zhàn)性的任務，因為有時必須更新一些管理服務。如果要向現(xiàn)有API添加新功能，則必須更改API網(wǎng)關中的API并部署新的Lambda函數(shù)。像Chalice或Serverless這樣的框架極大地簡化了整個部署過程。以下示例演示如何設置和部署由無服務器框架管理的簡單應用程序：

npm install serverless –g
serverless create --template aws-nodejs
serverless deploy

這三行代碼使用NPM安裝Serverless框架，在中創(chuàng)建一個簡單的項目節(jié)點.js，并將項目部署到AWS。Serverless使用AmazonCloudFormation作為基礎來存儲所有必要的配置。Serverless創(chuàng)建的每個資源都是通過一個中心CloudFormation模板創(chuàng)建的。例如，如果您想為映像添加一個額外的S3 bucket，可以在無服務器.yml-文件：

service: lambda-images
provider: aws
functions:
  ...

resources:
  Resources:
    ImagesBucket:
      Type: AWS::S3::Bucket
      Properties:
         BucketName: images-lambda
         # Or you could reference an environment variable
         # BucketName: ${env:BUCKET_NAME}

通過簡單的無服務器部署，將為您部署此自定義資源。

服務發(fā)現(xiàn)

微服務體系結構的主要挑戰(zhàn)之一是允許服務發(fā)現(xiàn)并相互交互。微服務體系結構的分布式特性不僅使服務難以通信，而且還帶來了一些有趣的挑戰(zhàn)，比如檢查這些系統(tǒng)的健康狀況以及何時有新的應用程序上線。此外，我們必須決定如何以及在何處存儲元存儲信息，例如應用程序可以使用的配置數(shù)據(jù)。下面我們將探討在基于微服務架構的AWS上執(zhí)行服務發(fā)現(xiàn)的幾種技術。

一種相當直接的方法是使用彈性負載平衡服務（ELB）。這種方法的優(yōu)點之一是，它提供運行狀況檢查，并在出現(xiàn)故障時自動注冊/注銷后端服務。將這些功能與DNS功能結合起來，就可以以最小的工作量和較低的成本構建一個簡單的服務發(fā)現(xiàn)解決方案。您可以為每個微服務配置一個自定義域名，并通過CNAME條目將域名與ELB的DNS名稱相關聯(lián)。然后在需要訪問的其他應用程序之間發(fā)布服務端點的DNS名稱。使用新的應用程序負載均衡器，可以使用創(chuàng)建一個具有規(guī)則的偵聽器來轉發(fā)基于URL路徑的請求。這稱為基于路徑的路由。您可以使用基于路徑的路由將流量路由到多個后端服務。例如，可以將常規(guī)請求路由到一個目標組，將渲染圖像的請求路由到另一個目標組。

Amazon Route 53可能是保存服務發(fā)現(xiàn)信息的另一個來源。路由53提供了幾個可用于服務發(fā)現(xiàn)的功能。私有托管區(qū)域功能允許它保存域或子域的DNS記錄集，并限制對特定虛擬私有云（VPC）的訪問。您可以將IP地址、主機名和端口信息注冊為特定微服務的SRV記錄，并限制對相關客戶端微服務的專有網(wǎng)絡的訪問。您還可以配置運行狀況檢查，定期驗證應用程序的狀態(tài)，并可能觸發(fā)資源記錄之間的故障轉移。

另一種方法是使用鍵/值存儲來發(fā)現(xiàn)微服務。盡管與其他方法相比，這種方法需要更多的時間來構建，但它提供了更多的靈活性和可擴展性，并且不會遇到DNS緩存問題。它還可以很好地與客戶端負載平衡技術（如Netflix Ribbon）配合使用?？蛻舳素撦d平衡可以幫助消除瓶頸并簡化管理。

最后，許多人使用服務發(fā)現(xiàn)軟件，如HashiCorp Consul或Netflix Eureka。Consul使服務注冊自己和通過DNS或HTTP接口發(fā)現(xiàn)其他服務變得簡單。此外，它還通過運行狀況檢查提供故障檢測，從而防止將請求路由到不健康的主機。下面的博客文章展示了如何使用amazonecs通過Consul設置服務發(fā)現(xiàn)。

分布式監(jiān)控

微服務體系結構可能由許多必須被監(jiān)控的“移動部分”組成。您可以使用amazoncloudwatch來收集和跟蹤度量，集中和監(jiān)視日志文件，設置警報，并自動對AWS環(huán)境中的更改做出反應。Amazon CloudWatch可以監(jiān)視AWS資源，如Amazon EC2實例、Amazon DynamoDB表和Amazon RDS DB實例，以及應用程序和服務生成的自定義度量，以及應用程序生成的任何日志文件。您可以使用amazoncloudwatch在系統(tǒng)范圍內(nèi)了解資源利用率、應用程序性能和運行狀況。Amazon CloudWatch提供了一個可靠、可擴展且靈活的監(jiān)控解決方案，您可以在幾分鐘內(nèi)開始使用。您不再需要設置、管理和擴展自己的監(jiān)控系統(tǒng)和基礎設施。在微服務架構中，使用amazoncloudwatch監(jiān)控定制度量的功能是一個額外的好處，因為開發(fā)人員可以決定應該為每個服務收集哪些度量。除此之外，還可以基于自定義度量實現(xiàn)動態(tài)伸縮。一致的日志記錄對于故障排除和確定問題至關重要。微服務允許生產(chǎn)比以往更多的版本，并鼓勵工程團隊對生產(chǎn)中的新特性進行實驗。了解客戶影響對于逐步改進應用程序至關重要。

將日志存儲在一個中心位置對于在分布式系統(tǒng)上進行調(diào)試和獲得聚合視圖至關重要。在AWS中，您可以使用Amazon CloudWatch日志來監(jiān)視、存儲和訪問來自Amazon Elastic Compute Cloud（amazonec2）實例、AWS CloudTrail或其他源的日志文件。amazonec2包括對awslogs日志驅(qū)動程序的支持，該驅(qū)動程序允許將容器日志集中到CloudWatch日志。有不同的選項來集中日志文件。大多數(shù)AWS服務已經(jīng)將日志文件集中化。AWS上日志文件的主要目的地是amazons3和amazoncloudwatch日志。日志文件是每個系統(tǒng)的敏感部分，幾乎每個進程都會生成日志文件。集中式日志解決方案將所有日志聚合在一個中心位置，以便能夠使用amazonemr或amazonredshift等工具搜索和分析這些日志。在許多情況下，一組微服務協(xié)同工作來處理請求。想象一下，一個復雜的系統(tǒng)由幾十個微服務組成，而調(diào)用鏈中的一個服務發(fā)生了錯誤。即使每個微服務都正確地記錄日志，并且日志都整合在一個中央系統(tǒng)中，也很難找到所有相關的日志消息。

correlationid的中心思想是，如果面向用戶的服務接收到請求，則創(chuàng)建一個特定的ID。該ID可以在HTTP報頭中傳遞（例如，使用諸如“x-correlation-ID”之類的報頭字段）到每一個其他服務或傳遞的有效負載中。ID可以包含在每個日志消息中，以查找特定請求的所有相關日志消息。為了獲得日志文件中調(diào)用的正確順序，一個好方法是在頭中發(fā)送一個計數(shù)器，如果請求流經(jīng)體系結構，計數(shù)器將遞增。springcloud提供了一個稱為Sleuth的相關ID實現(xiàn)，它可以用于分布式跟蹤，例如Zipkin。Zipkin是一個分布式跟蹤系統(tǒng)。它有助于收集解決微服務體系結構中延遲問題所需的時間數(shù)據(jù)。使用springcloudsleuth非常簡單，只需將Sleuth添加到Spring啟動應用程序的類路徑中，相關數(shù)據(jù)就會被收集到日志中。在日志中放置相關ID的HTTP處理程序示例如下所示：

@RestController
public class BaseController {
  private static Logger log = LoggerFactory.getLogger(BaseController);
  @RequestMapping("/")
  public String base() {
    log.info("Handling base");
    ...
    return "Hello World";
  }
}

閑談

通過將單片應用程序分解為小型微服務，通信開銷會增加，因為微服務必須相互通信。在許多實現(xiàn)中，restoverhttp被用作通信協(xié)議，它相當輕，但是高容量可能會導致問題。在某些情況下，考慮整合來回發(fā)送大量消息的服務可能是有意義的。如果您發(fā)現(xiàn)自己處于這樣一種情況：為了減少聊天，您整合了越來越多的服務，那么您應該檢查您的問題域和域模型。對于微服務來說，使用像HTTP這樣的簡單協(xié)議是很常見的。服務交換的消息可以以不同的方式編碼，例如，以JSON或YAML等人類可讀的格式或有效的二進制格式編碼。HTTP是一種同步協(xié)議?？蛻舳税l(fā)送請求并等待響應。通過使用異步IO，客戶機的當前線程不必等待響應，但可以執(zhí)行不同的操作。

結論

微服務體系結構是一種克服傳統(tǒng)單片體系結構局限性的分布式方法。雖然微服務有助于擴展應用程序和組織，同時縮短周期，但它們也帶來了一些挑戰(zhàn)，這些挑戰(zhàn)可能會導致額外的體系結構復雜性和操作負擔

AWS提供了大量的托管服務組合，幫助產(chǎn)品團隊構建微服務體系結構，并將體系結構和操作復雜性降至最低。本文將指導您了解相關的AWS服務，以及如何使用AWS服務實現(xiàn)典型的模式，例如Service Discovery。