楊波微服務技術專家

by Jake Lumetta

杰克·盧米塔(Jake Lumetta)

專家稱，這些是最有效的微服務測試策略 (These are the most effective microservice testing strategies, according to the experts)

Testing microservices is hard. More specifically, end-to-end testing is hard, and that’s something we’ll discuss in greater detail in this article.

測試微服務很難。更具體地說，端到端測試很困難，這是我們將在本文中詳細討論的內容。

But first, a quick story.

但首先，一個簡短的故事。

I learned just how hard microservice testing could be when I first dove into a tech stack with seven separate microservices. Each had its own code base, dependency management, feature branches, and database schema — which also happened to have a unique set of migrations.

當我首次涉足具有七個獨立微服務的技術堆棧時，我了解了微服務測試的難度。每個數據庫都有自己的代碼庫，依賴關系管理，功能分支和數據庫架構-碰巧還具有一組獨特的遷移。

Talk about hectic.

談忙。

The approach we took was to run everything locally. So that meant, at any given point in time when I want to run end-to-end tests, I would need to go through the following five steps for each of the seven microservices:

我們采取的方法是在本地運行所有內容。因此，這意味著，在我要運行端到端測試的任何給定時間點，對于七個微服務中的每個微服務，我都需要經歷以下五個步驟：

Ensure I was on the correct code branch (either master or feature_xyz)
確保我在正確的代碼分支上(master或feature_xyz)
Pull down the latest code for that branch
提取該分支的最新代碼
Ensure all dependencies were up to date
確保所有依賴項都是最新的
Run any new database migrations
運行任何新的數據庫遷移
Start the service
啟動服務

This was just a baseline requirement to enable tests to be run. Often times, I would forget to perform one of these steps for a service and spend 10–15 minutes debugging the issue. Once I finally had all the services happy and running, I could then begin to kick off the test suite. This experience sure made me miss the days of testing one big monolith.

這只是使測試能夠運行的基本要求。通常，我會忘記為服務執行以下步驟之一，而花10到15分鐘來調試問題。一旦我終于滿意并運行了所有服務，便可以開始測試套件了。這種經歷肯定使我懷念測試一個大型整體裝置的日子。

So yes, I discovered that end-to-end microservice testing is hard — and gets exponentially harder with each new service you introduce. But fear not, because there are ways to make testing microservices easier. I’ve spoken to several CTOs about how they came up with their own creative ways of tackling this complex issue.

因此，是的，我發現端到端的微服務測試非常困難，并且您引入的每一項新服務都變得越來越困難。但是不要擔心，因為有多種方法可以使微服務的測試變得更加容易。我曾與幾位首席技術官談過他們如何提出自己的創造性方法來解決這一復雜問題。

常見的微服務測試方法 (Common microservice testing methods)

單元測試 (Unit Testing)

A microservice may be smaller by definition, but with unit testing, you can go even more granular. A unit test focuses on the smallest part of a testable software to ascertain whether that component works as it should. Renowned software engineer, author, and international speaker Martin Fowler breaks unit testing down into two categories:

從定義上講，微服務可能會更小，但是通過單元測試，您可以變得更加細化。單元測試專注于可測試軟件的最小部分，以確定該組件是否可以正常工作。著名的軟件工程師，作家和國際發言人Martin Fowler 將單元測試分為兩類：

Sociable unit testing: This unit testing method tests the behavior of modules by observing changes in their state.
社交單元測試：這種單元測試方法通過觀察模塊狀態的變化來測試模塊的行為。
Solitary unit testing: This method focuses on the interactions and collaborations between an object and its dependencies, which are replaced by test doubles.
孤立單元測試：此方法著重于對象及其依賴項之間的交互和協作，這些交互和協作被替換為測試雙精度。

While these unit testing strategies are distinct, Fowler puts forth that they aren’t competing — they can be used in tandem to solve different testing problems.

盡管這些單元測試策略是截然不同的，但Fowler提出它們并沒有競爭-可以串聯使用它們來解決不同的測試問題。

During a discussion with David Strauss, CTO of Pantheon, David told me that “the opportunity is that Microservices are very straightforward to actually do unit testing on.”

在與萬神殿CTO大衛·斯特勞斯的討論中，大衛告訴我：“機會是微服務非常容易直接進行單元測試。”

整合測試 (Integration testing)

With integration tests, you’re doing what it sounds like you’re doing: testing the communication paths and interactions between components to detect issues. According to Fowler, an integration test “exercises communication paths through the subsystem to check for any incorrect assumptions each module has about how to interact with its peers.”

使用集成測試，您可以按聽起來的方式做：測試組件之間的通信路徑和交互以檢測問題。根據Fowler的說法，集成測試“通過子系統執行通信路徑，以檢查每個模塊有關如何與對等方進行交互的任何不正確的假設。”

An integration test usually tests the interactions between the microservice and external services, like another microservice or datastore.

集成測試通常測試微服務和外部服務(例如另一個微服務或數據存儲)之間的交互。

Pawel ?Ledwon?, Platform Lead at Pusher, informed me that his team “lean[s] towards integration testing. Unit tests are still useful for some abstractions, but for user-facing features they are difficult to mock or skip important parts of the system.”

Pusher平臺負責人Pawel``Ledwon''告訴我，他的團隊``傾向于集成測試''。單元測試對于某些抽象仍然有用，但是對于面向用戶的功能，它們很難模擬或跳過系統的重要部分。”

Not everybody I spoke to was a fan of the process. Mosquera’s take on the subject of integration testing, for example, is well worth noting:

與我交談的并不是每個人都喜歡這個過程。例如，Mosquera對集成測試的看法很值得一提：

Integration testing is very error prone and costly, in terms of man-hours. The ROI just isn’t there. Each individual integration test brings small marginal coverage of use cases.

就工時而言，集成測試非常容易出錯且成本很高。投資回報率不存在。每個單獨的集成測試都會帶來用例的少量邊際覆蓋。

端到端測試 (End-to-end testing)

Last but not least is end-to-end testing, which — as previously mentioned — can be a difficult task. That’s because it involves testing every moving part of the microservice, ensuring that it can achieve the goals you built it for.

最后但并非最不重要的一點是端到端測試，如前所述，這可能是一項艱巨的任務。這是因為它涉及測試微服務的每個移動部分，以確保其可以實現為其構建的目標。

Fowler wrote the following:

福勒寫道：

end-to-end tests may also have to account for asynchrony in the system, whether in the GUI or due to asynchronous backend processes between the services.

不管是在GUI中還是由于服務之間的異步后端進程，端對端測試都可能不得不考慮系統中的異步性。

He goes on to explain how these factors can result in “flakiness, excessive test runtime and additional cost of maintenance of the test suite.”

他繼續解釋了這些因素如何導致“松散，測試時間過多和測試套件的維護成本增加”。

The best advice I can give when it comes to end-to-end testing is to limit the amount of times you attempt it per service. A healthy balance between the other microservice testing strategies mentioned — like unit testing and integration testing — will help you weed out smaller issues.

關于端到端測試，我能提供的最佳建議是限制每次服務嘗試嘗試的次數。在上述其他微服務測試策略(例如單元測試和集成測試)之間保持良好的平衡，將有助于您清除較小的問題。

An end-to-end test is larger by definition, takes more time, and can be far easier to get wrong. To keep your costs low and avoid time-sink, stick to end-to-end testing when all other means of testing have been exhausted, and as a final stamp of quality assurance.

根據定義，端到端測試更大，花費更多時間并且容易出錯。為了降低成本并避免浪費時間，請在所有其他測試手段都用盡后堅持進行端到端測試，并以此作為最終的質量保證。

測試微服務的挑戰 (The challenges of testing microservices)

Microservices (compared to a monolith) require extra steps, like managing multiple repositories and branches, each with their own database schemas. But the challenges can run deeper than that.

微服務(相對于整體服務)需要額外的步驟，例如管理多個存儲庫和分支，每個存儲庫和分支都有自己的數據庫架構。但是挑戰可能比這更深。

Here are a few key challenges associated with testing microservices:

以下是與測試微服務相關的一些關鍵挑戰：

Availability: Since different teams may be managing their own microservices, securing the availability of a microservice (or, worse yet, trying to find a time when all microservices are available at once), is tough.
可用性：由于不同的團隊可能管理著自己的微服務，因此確保微服務的可用性(或者更糟糕的是，試圖找到同時提供所有微服務的時間)非常困難。
Fragmented and holistic testing: Microservices are built to work alone, and together with other loosely coupled services. That means developers need to test every component in isolation, as well as testing everything together.
零散的整體測試：微服務被構建為可以單獨工作，并與其他松散耦合的服務一起工作。這意味著開發人員需要單獨測試每個組件，以及一起測試所有組件。
Knowledge gaps: Particularly with integration testing (which we will address later in this article), whoever conducts the tests will need to have a strong understanding of each service in order to write test cases effectively.
知識差距：尤其是對于集成測試(我們將在本文后面介紹)，進行測試的人員必須對每種服務都有深刻的了解，才能有效地編寫測試用例。

According to Oleksiy Kovyrin, Head of Swiftype SRE at Elastic,

Elastic的Swiftype SRE負責人Oleksiy Kovyrin表示，

One important issue we have to keep in mind while working with microservices is API stability and API versioning. To avoid breaking applications depending on a service, we need to make sure we have a solid set of integration tests for microservice APIs and, in case of a breaking change, we have to provide a backwards-compatible way for clients to migrate to a new version at their own pace to avoid large cross-service API change rollouts.

使用微服務時，我們必須牢記的一個重要問題是API穩定性和API版本控制。為了避免根據服務中斷應用程序，我們需要確保我們有一套針對微服務API的可靠的集成測試，并且在發生重大更改的情況下，我們必須為客戶提供向后兼容的方式來遷移到新的自行調整版本，以免大規模推出跨服務API更改。

Stefan Zier, Chief Architect at Sumo Logic, also reiterated to me that microservice testing is indeed “very, very difficult.”

Sumo Logic的首席架構師Stefan Zier也向我重申，微服務測試確實“非常非常困難”。

“Especially once you go towards more continuous deployment. We’ve invested and continue to invest fairly heavily into integration testing, unit testing, and would do a lot more if we had the people to do it,” Zier told me.

“特別是一旦您要進行更連續的部署。 Zier告訴我，我們已經投資并且繼續在集成測試，單元測試上投入相當大的資金，如果讓我們的人來做，它將做得更多。

With that being said, he admitted that, at certain stages, when Sumo Logic wants to test their services holistically, “more or less [the] entire company [becomes] a quality assurance team in a sense.”

話雖如此，他承認，在某些階段，當Sumo Logic想要整體測試他們的服務時，“整個公司或多或少都在某種意義上成為了質量保證團隊。”

解決方案：針對初創企業的五種微服務測試策略 (Solution: Five microservice testing strategies for startups)

Yes, testing microservices can be difficult, but given all the benefits of microservices, foregoing them because of testing challenges isn’t the right path. To tackle these challenges, I got insight from several CTOs and distilled five strategies they used to successfully approach testing microservices.

是的，測試微服務可能很困難，但是鑒于微服務的所有好處，由于測試挑戰而放棄它們并不是正確的方法。為了應對這些挑戰，我從幾個CTO那里獲得了見識，并提煉了他們成功用于測試微服務的五種策略。

1.以文件為先的策略 (1. The documentation-first strategy)

Chris McFadden, VP of Engineering Sparkpost, summarized the documentation-first strategy quite nicely during our discussion:

在我們的討論中，Sparkpost工程副總裁Chris McFadden很好地總結了文檔優先的策略：

We follow a documentation first approach so all of our documentation is in markdown in GitHub. Our API documents are open source, so it’s all public. Then, what we’ll do is before anybody writes any API changes or either a new API or changes to an API, they will update the documentation first, have that change reviewed to make sure that it conforms with our API conventions and standards which are all documented, and make sure that there’s no breaking change introduced here. Make sure it conforms with our naming conventions and so forth as well.

我們遵循文檔優先的方法，因此我們所有的文檔都在GitHub的markdown中。我們的API文檔是開源的，因此都是公開的。然后，我們要做的是在任何人編寫任何API更改或新API或對API進行更改之前，他們將首先更新文檔，對更改進行審核以確保其符合我們的API約定和標準。所有文件均已記錄在案，并確保此處沒有引入重大更改。確保它也符合我們的命名約定等。

If you’re willing to go one step further, you could dabble in API contract testing, which — as previously mentioned — involves writing and running tests that ensure the explicit and implicit contract of a microservice works as it should.

如果您愿意更進一步，則可以涉足API合約測試，如前所述，API合約測試涉及編寫和運行測試，以確保微服務的顯式和隱式契約能夠正常工作。

2.全棧即裝即用策略 (2. The full stack in-a-box strategy)

The full stack in-a-box strategy entails replicating a cloud environment locally and testing everything all in one vagrant instance (“$ vagrant up”). The problem? It’s extremely tricky, as software engineer Cindy Sridharan of Imgix explained in a blog post:

完整堆棧即裝即用策略需要在本地復制云環境，并在一個無所事事的實例中測試所有內容(“ $ vagrant up”)。問題？正如Imgix的軟件工程師Cindy Sridharan在博客文章中所述，這非常棘手：

I’ve had first hand experience with this fallacy at a previous company I worked at where we tried to spin up our entire stack in a [local] vagrant box. The idea, as you might imagine, was that a simple vagrant up should enable any engineer in the company (even frontend and mobile developers) to be able to spin up the stack in its entirety on their laptops.

我曾在一家以前的公司工作過，曾有過這種謬論的第一手經驗，在那家公司，我們試圖在[本地]無家可歸的盒子中旋轉整個堆棧。就像您可能想像的那樣，想法是，只需進行一次簡單的游蕩，即可使公司中的任何工程師(甚至是前端和移動開發人員)都能夠在筆記本電腦上旋轉整個堆棧。

Sridharan goes on to detail how the company only had two microservices, a gevent based API server and some asynchronous Python background workers. A relatively simple setup, by all means.

Sridharan繼續詳細介紹了該公司如何只有兩個微服務，一個基于gevent的API服務器和一些異步Python后臺工作者。絕對是一個相對簡單的設置。

“I remember spending my entire first week at this company trying to successfully spin up the VM locally only to run into a plethora of errors. Finally, at around 4:00pm on the Friday of my first week, I’d successfully managed to get the Vagrant setup working and had all the tests passing locally. I remember feeling incredibly exhausted,” she narrated.

“我記得整個第一周都在這家公司工作，試圖在本地成功啟動虛擬機，但是卻遇到了很多錯誤。終于，在我第一周的星期五下午4:00左右，我成功地使Vagrant設置正常工作，并使所有測試都在本地通過。我記得我感到非常疲憊，”她說。

In addition, Stefan Zier, Chief Architect at Sumo Logic, explained to me that — on top of being difficult to pull off — this localized testing strategy simply doesn’t scale:

此外，Sumo Logic的首席架構師Stefan Zier向我解釋說，除了難以實現之外，這種本地化的測試策略根本無法擴展：

“[With] a local deployment, we run most of the services there so you get a fully running system and that’s now stretching even the 16GB RAM machines quite hard. So that doesn’t really scale,” he said.

“在本地部署中，我們在那里運行大多數服務，因此您將獲得一個完全運行的系統，而現在即使16GB RAM機器也很難擴展。因此，這并沒有真正擴大規模，”他說。

3. AWS測試策略 (3. The AWS testing strategy)

This third strategy involves spinning up an Amazon Web Services (AWS) infrastructure for each engineer to deploy and run tests on. This is a more scalable approach to the full stack in-a-box strategy discussed above.

第三種策略涉及為每個工程師擴展Amazon Web Services(AWS)基礎架構，以部署和運行測試。這是對上面討論的全棧即用策略的一種更具可擴展性的方法。

Zier called this a “personal deployment [strategy], where everyone here has their own AWS account.”

Zier將此稱為“個人部署[策略]，這里的每個人都擁有自己的AWS賬戶。”

“You can push the code that’s on your laptop up into AWS in about ten minutes and just run it in like a real system,” he said.

他說：“您可以在大約十分鐘的時間內將筆記本電腦上的代碼推送到AWS中，然后像實際系統一樣運行它。”

4.共享測試實例策略 (4. The shared testing instances strategy)

I like to think of this fourth strategy as a hybrid between full stack in-a-box and AWS testing. That’s because it involves developers working from their own, local station, while leveraging a separate, shared instance of a microservice to point their local environment at during testing.

我喜歡將第四種策略視為完整堆棧即裝式測試與AWS測試之間的混合體。這是因為它涉及開發人員在自己的本地工作站上工作，同時利用單獨的共享微服務實例在測試期間將其本地環境指向。

Steven Czerwinski, Head of Engineering, Scaylr, explained how this can work in practice:

Scaylr工程主管Steven Czerwinski解釋了這在實踐中如何工作：

Some of [our] developers run a separate instance of a microservice just to be used for testing local builds. So imagine you’re a developer, you’re developing on your local workstation, and you don’t have easy way of launching the image parser. However, your local builder would just point to a test image parser that’s running in the Google infrastructure.

[我們的]一些開發人員運行一個微服務的單獨實例，僅用于測試本地構建。因此，假設您是一名開發人員，正在本地工作站上進行開發，并且沒有啟動圖像解析器的簡便方法。但是，您的本地構建器只會指向在Google基礎架構中運行的測試圖像解析器。

5.存根策略 (5. The stubbed services strategy)

And finally, we have the stubbed services testing strategy.

最后，我們有存根服務測試策略。

Zier laid out SumoLogic’s approach to stubbed service testing by telling me how, “stubbing let’s you write these marks or ‘stubs’ of microservices that behave as if they were the right service and they advertise themselves in our service discovery as if they were real service, but they’re just a dummy imitation,” he explained.

Zier告訴我如何，SuerLogic展示了SumoLogic進行存根服務測試的方法，“存根讓您寫下這些標記或微服務的“存根”，它們的行為就像是正確的服務，并且在我們的服務發現中做廣告，就好像它們是真實的服務一樣。，但它們只是一個虛擬的模仿，”他解釋說。

For example, testing a service may necessitate that the service becomes aware that a user carries out a set of tasks. With stubbed services, you can pretend that user (and his tasks) have taken place without the usual complexities that come with that. This approach is a lot more lightweight compared to running services in their totality.

例如，測試服務可能需要使服務意識到用戶執行了一組任務。使用存根服務，您可以假設用戶(及其任務)已經發生，而沒有隨之而來的通常的復雜性。與整體上運行服務相比，此方法輕巧得多。

幫助您測試微服務的工具 (Tools to help you test microservices)

Here’s a list of tools that have benefited me during my own microservice testing experiences, bolstered by some recommendations from the pool of CTOs and senior developers:

以下是在我自己的微服務測試經驗中受益的工具列表，并得到了CTO和高級開發人員的建議：

Hoverfly: simulate API latency and failures.
Hoverfly ：模擬API延遲和失敗。
Vagrant: build and maintain portable virtual software development environments
Vagrant ：構建和維護便攜式虛擬軟件開發環境
VCR: a unit testing tool
VCR ：單元測試工具
Pact: frameworks consumer-driven contracts testing.
契約：構架消費者驅動的合同測試。
Apiary: API documentation tool
養蜂場：API文檔工具
API Blueprint: design and prototype APIs
API藍圖：設計和原型API
Swagger: design and prototype APIs
Swagger ：設計和原型API

微服務測試：困難，但值得 (Microservices testing: difficult, but worth it)

Testing your microservices won’t be a walk in the park, but the additional work is worth the benefits of having a microservice architecture.

測試您的微服務并不是在公園里散步，但是額外的工作值得擁有微服務架構的好處。

Plus, the microservice testing strategies adopted by the likes of SumoLogic and Scaylr should help smooth the process out. Here’s a quick recap of those strategies:

另外，SumoLogic和Scaylr等公司采用的微服務測試策略應有助于簡化流程。以下是這些策略的簡要介紹：

The documentation-first strategy
以文檔為先的策略
The full stack in-a-box strategy
全棧即裝即用策略
The AWS testing strategy
AWS測試策略
The shared testing instances strategy
共享測試實例策略
The stubbed service strategy
存根策略

Naturally, you may need to tweak each strategy to match your unique circumstances, but with some good old fashioned trial and error, your microservice testing strategy should come into its own.

自然地，您可能需要調整每種策略以適應您的獨特情況，但是通過一些良好的老式嘗試和錯誤，您的微服務測試策略應該成為自己的策略。

If you’ve enjoyed this article, please help it spread by clapping below! For more content like this, follow us on Twitter and subscribe to our blog.

如果您喜歡這篇文章，請通過下面的鼓掌幫助傳播！ 有關此類的更多內容，請在Twitter上關注我們并訂閱我們的博客。

Jake Lumetta is the CEO of ButterCMS, and is publishing Microservices for Startups.

杰克Lumetta是首席執行官ButterCMS ，并發布了創業微服務。

And if you want to add a blog or CMS to your website without messing around with Wordpress, you should try Butter CMS.

而且，如果您想在您的網站上添加博客或CMS而不用弄亂Wordpress，則應該嘗試Butter CMS 。