While there are many patterns for doing microservices well, an equally significant number of patterns exist that can quickly get any development team into trouble. The following are some of the don’ts while developing microservices:
虽然有许多关于如何做好微服务的模式，但同样存在大量可能导致任何开发团队迅速陷入困境的模式。在开发微服务时，以下是一些需要避免的事项：

Don’t build microservices 不要构建微服务

The first rule of microservices is don’t start with microservices. When you determine that the monolithic application's complexity negatively affects application development and maintenance, consider refactoring that application into smaller services.
微服务的首要规则是不要一开始就采用微服务。当你确定单体应用的复杂性对应用开发和维护产生负面影响时，考虑将该应用重构为更小的服务。

When the application becomes too large to update and maintain easily, these microservices will become ideal for breaking down the complexity and making the application more manageable.
当应用程序变得过于庞大，难以轻松更新和维护时，这些微服务将成为分解复杂性的理想选择，并使应用程序更易于管理。

However, until you feel that pain, you don’t even have a monolith that needs refactoring.
然而，在你感受到这种痛苦之前，你甚至没有一个需要重构的单体应用程序。

Not taking automation seriously 不重视自动化

If you have a monolith application, you only need to deploy one piece of software. Once you move to a microservices architecture, you will have more than one application with each having different code, test, and deploy cycles.
如果你有一个单体应用程序，你只需要部署一个软件组件。一旦你转向微服务架构，你将会有多个应用程序，每个应用程序都有不同的代码、测试和部署周期。

Attempting to build microservices without either:
试图在不具备以下任何一项的情况下构建微服务：

• proper deployment and monitoring automation, or 
  适当的部署和监控自动化，或
• managed cloud services to support your now sprawling, heterogenous infrastructure
  支持您现在庞大且异构基础设施的管理云服务

is asking for a lot of unnecessary trouble.
将会带来许多不必要的麻烦。

So, when you are building microservices, always use DevOps or cloud services.
因此，在构建微服务时，始终使用 DevOps 或云服务。

Don’t build nanoservices 不要构建纳米服务

If you go too far with the micro in microservices, you could easily find yourself building nanoservices! The complexity of which will outweigh the overall gains of microservices architecture.
如果你在微服务中对“微”的理解过于极端，你可能会轻易发现自己正在构建纳米服务！其复杂性将超过微服务架构的整体收益。

Lean toward creating larger services and create smaller services when:
倾向于创建更大的服务，并在以下情况下创建较小的服务：

• Deploying changes becomes difficult
  部署变更变得困难
• The common data model becomes overly complex
  通用数据模型变得过于复杂
• Loading and scaling requirements no longer synchronize and affect application performance
  加载和扩展需求不再同步，并影响应用程序性能

Don’t turn into SOA 不要转向面向服务的架构

The two concepts; microservices and service-oriented architecture (SOA) are often confused with one another because, at their most basic level, both build reusable individual components that can be consumed by other applications.
微服务和服务导向架构（SOA）这两个概念经常被混淆，因为它们最基本的功能都是构建可重用的独立组件，这些组件可以被其他应用程序消费。

However, microservices are fine-grained with independent data storage for each, that is, the bounded context.
然而，微服务是细粒度的，每个都有独立的数据存储，即边界上下文。

A microservices project that morphs into an SOA project will likely buckle under its own weight.
一个逐渐演变成面向服务的架构（SOA）的微服务项目可能会因自身重量而崩溃。

Don’t build a gateway for each service 不要为每个服务构建网关

Instead of implementing end-user authentication, throttle, orchestrate, transform, route, and analytics in each service, you should use an API Gateway.
与其在每个服务中实现最终用户身份验证、限流、编排、转换、路由和分析，你应该使用 API 网关。

An API gateway is an API management tool that sits between a client and your collection of backend services.
API 网关是一个位于客户端和你的后端服务集合之间的 API 管理工具。

This will become central to the above-mentioned non-functional concerns and will avoid re-engineering them with each service.
这将成为上述非功能性问题的核心，并避免在每个服务中重新工程它们。

Conclusion 结论

The aim of microservices is to solve the three most frequent challenges, that is, enhance customer experience, be flexible to new requirements, and reduce costs by providing business functions as fine-grained services.
微服务旨在解决三个最常见挑战，即提升客户体验、灵活应对新需求，并通过将业务功能作为细粒度服务来降低成本。

But while doing so, you should avoid the pitfall of the above-mentioned anti-patterns making microservices a nuisance to your development, delivery, and management requirements.
但在实现这一目标时，应避免上述反模式带来的陷阱，以免微服务成为您开发、交付和管理需求的负担。