I have been writing about Microservices for quite a few years, both its benefits and its downside. I also raised the flag for newbies not to jump into Microservices without having a proper understanding of the complexity they are getting into, by merely following the trend.

多年来，我一直在撰写有关微服务的文章，包括它的优点和缺点。 我还标记了新手不要仅仅通过遵循趋势就不了解微服务所进入的复杂性就跳入微服务的旗帜。

When it comes to Microservices, the success stories and the concepts are truly mesmerizing. Having a collection of services of each doing one thing in the business domain builds a perfect image of a lean architecture. However, we shouldn’t forget that these services need to work together to deliver business value to their end-users.

当谈到微服务时，成功的故事和概念确实令人着迷。 在业务领域中，将每项服务都做一件事情的集合可以构建精益架构的完美形象。 但是，我们不应忘记，这些服务需要协同工作才能为最终用户提供业务价值。

全面了解业务领域 (Knowing business domain Inside-Out)

In the real world, we offer services to end-users in the form of web applications, mobile apps, IoT, or even APIs for integrations. So, if we follow the Microservices architecture, we are talking about Microservices communicating with each other in a particular way.

在现实世界中，我们以Web应用程序，移动应用程序，IoT，甚至集成API的形式向最终用户提供服务。 因此，如果我们遵循微服务架构，那么我们所谈论的是微服务以特定方式相互通信。

So if you are new to Microservices, before adopting it, you need first to answer the following question.

因此，如果您不熟悉微服务，那么在采用微服务之前，您需要首先回答以下问题。

问题1 ：您是否完全了解自己的业务领域，并合理地预测不久将会发生什么变化？ (Question 1: Do you know your business domain inside out and reasonably predict what will change shortly?)

Knowing the business domain inside out and the experience with the domain-driven design is crucial to identify the bounded context of each service. Since we allocate teams per each Microservice and allow them to work with minimal interference, getting the bounded context wrong would increase the communication overhead and inter-team dependencies, impacting the overall development speed. So for a project starting from scratch, selecting Microservices is a risky move.

全面了解业务领域以及领域驱动设计的经验对于确定每个服务的有限上下文至关重要。 由于我们为每个微服务分配团队，并允许他们以最小的干扰进行工作，因此，错误地定义有界上下文会增加通信开销和团队之间的依存关系，从而影响总体开发速度。 因此，对于从头开始的项目，选择微服务是一个冒险的举动。

进入分布式系统世界 (Entering the world of Distributed Systems)

“Distributed Systems are Hard” — Anonymous

“分布式系统很难”-匿名

But what’s the relationship between distributed systems and Microservices. The connection is simple, and when you build Microservices, you directly dive into the realm of distributed systems kind of in advanced mode. They may solve specific problems, but will also introduce others.

但是分布式系统和微服务之间是什么关系。 连接很简单，并且在构建微服务时，您可以直接进入高级模式下的分布式系统领域。 他们可能会解决特定的问题，但也会介绍其他问题。

In fact, its likely not to experience any of the issues with Monoliths, in your software product lifetime, that are worth solved with Microservices.

实际上，在您的软件产品生命周期中，Monoliths可能不会遇到任何值得微服务解决的问题。

问题2 ：您打算通过采用微服务架构来实现什么？ (Question 2: What are you trying to achieve by adopting Microservices Architecture?)

Microservices isn’t a silver bullet or a superb architecture style that is for everyone. Since we need to deal with distributed systems, it could be an overkill for many. Therefore, it’s essential to assess whether the issues you are experiencing with the Monolith are solvable by Microservices.

微服务不是适合所有人的灵丹妙药，也不是精湛的架构风格。 由于我们需要处理分布式系统，因此对许多人来说可能是一个过大的杀伤力。 因此，必须评估Microservices是否可以解决您在Monolith中遇到的问题。

问题3 ：您和您的团队是否有足够的经验来处理微服务所需的分布式系统？ (Question 3: Are you and your team experienced enough to work with distributed systems required for Microservices?)

Working with a distributed system will put you in challenges such as distributed telemetry and monitoring, network & communication, fault-tolerant design, distributed transactions, event-driven architecture, containers, and middleware that need a specialized set of design skills and experience. Although there are reference architectures and guides available on the internet, using these properly is the main challenge.

使用分布式系统会给您带来挑战，例如分布式遥测和监视，网络和通信，容错设计，分布式事务，事件驱动的体系结构，容器以及需要专门的设计技能和经验的中间件。 尽管Internet上有参考体系结构和指南，但是正确使用它们是主要的挑战。

跟随名人 (Following the Celebrities)

I have seen famous case studies from Amazon, Netflix absorbing Microservices. You might also feel that why not step up and follow their success paths to the next big thing. You might even get the buying from your business counterparts. The fun part is the non-tech people will also provoke you by asking why not consider Microservices?

我已经看到了来自亚马逊的著名案例研究，Netflix吸收了微服务。 您可能还会觉得，为什么不加紧努力，沿着他们的成功之路迈向下一件大事。 您甚至可以从同行那里获得购买。 有趣的是，非技术人员还会问为什么不考虑微服务，从而激怒您？

At the end of the day, who doesn’t want to become Amazon or Netflix and follow their paths, right?

归根结底，谁不想成为Amazon或Netflix并遵循自己的道路，对吗？

These influences might set an extremely positive impression on Microservices. You might buy the point from the case study or watching the video and convince your self that Monoliths are evil and Microservices are the way to the future.

这些影响可能会对微服务产生非常积极的印象。 您可能会从案例研究或观看视频中获得启示，并说服自己相信Monoliths是邪恶的，而微服务是通往未来的道路。

问题4 ：您是否有足够的时间，精力和金钱来投资微服务？ (Question 4: Do you have enough time, effort, and money to invest in Microservices?)

You might miss the point of how much effort and time it took for them to migrate their Monoliths to Microservices. These projects could quickly go for a couple of years. Even you start a new project with Microservices, that doesn’t guarantee that you will save time and money due to complexities and productivity challenges.

您可能会忘记他们将Monoliths迁移到微服务所花费的精力和时间。 这些项目可能很快就会进行几年。 即使您使用Microservices启动了一个新项目，由于复杂性和生产力挑战，也不能保证您会节省时间和金钱。

预先大设计？ (Big design upfront?)

I have talked with some people who have followed full-fledge Microservices from the beginning and experiencing delays than usual, still convinced that it will solve the problem in the future.

我已经与一些从一开始就遵循全功能微服务并且经历了比平时更多的延迟的人进行了交谈，他们仍然坚信它将在将来解决问题。

Microservices will slow you down, take my word for it. If time to market is important, it’s better to go with a Monolith.

微服务会让您放慢速度，请相信我。 如果上市时间很重要，最好选择Monolith。

Dealing with Distributed systems, Microservices communication, extra effort on data consistency, extra effort on DevOps efforts, are overheads for software development.

在处理分布式系统时，微服务通信，数据一致性方面的额外努力，DevOps方面的额外努力是软件开发的开销。

问题5 ：您是否了解在解决架构和技术方面有足够的经验？ (Question 5: Do you understand the architectural and technical overheads with sufficient experience in solving them?)

Unless you build a Monolith and use best practices from Microservices, you might fall into this trap.

除非您构建Monolith并使用微服务的最佳实践，否则您可能会陷入此陷阱。

使其发展 (Make it Evolve)

If you have read the article up to hear, you will feel that I’m just causing fear in adopting Microservices. My whole purpose here is to make you aware of the risks of directly jumping into Microservices, which I learned the hard way. The bright side is that these journies taught me how to do better with Microservices.

如果您已读完这篇文章以听取您的意见，您会觉得我在采用微服务方面引起了恐惧。 我的整个目的是让您意识到直接跳入微服务的风险，这是我学到的。 好的一面是，这些旅程教会了我如何更好地使用微服务。

As a litmus test, I have put five questions that you can use as a checklist before adopting Microservices. If the answer is “YES” for all the questions, there is hope that you will make rational decisions in your journey. Otherwise, it’s better to stay away from Microservices since the learning would be costly for the business and has the likelihood of risking the entire project.

作为试题，在采用微服务之前，我提出了五个问题可以用作检查清单。 如果所有问题的答案都是“是”，则希望您在旅途中做出理性的决定。 否则，最好不要使用微服务，因为学习对企业来说是昂贵的，并且有可能冒险整个项目。

遵循正确的架构过程。 (Follow the proper architecture process.)

So my first tip is to decide on the architecture styles by identifying the quality attributes and using the right tactics. Knowing their trade-offs is the right way to move ahead in selecting the architecture styles, tools, and technologies for the application.

因此，我的第一个技巧是通过识别质量属性并使用正确的策略来决定体系结构样式。 了解它们之间的权衡是正确选择应用程序的体系结构样式，工具和技术的正确方法。

Following this approach will keep you away from taking drastic architectural choices, which will also keep Microservices a distant reality in most of the cases.

采用这种方法将使您远离繁琐的体系结构选择，这也将使大多数情况下微服务成为遥不可及的现实。

从Monolith到微服务 (Evolving from Monolith to Microservices)

If you already have a well-established business and experiencing architectural and technical difficulties with its growth, that that the right time to think of Microservices.

如果您已经拥有一家成熟的企业，并且在业务增长方面遇到架构和技术方面的困难，那么就该考虑微服务了。

If you grasp the message from Amazon and Netflix success stories, remember that they were successful with the Monolith as a business at first where they had the money and people with enough experience to do the transformation. These migrations might take months or years. But these businesses have the financials to back the digital transformation, knowing overall benefits at their scale.

如果您掌握了来自亚马逊和Netflix成功案例的信息，请记住，它们最初是凭借Monolith作为一家企业而成功的，他们拥有足够的资金和经验丰富的人员来进行转型。 这些迁移可能需要数月或数年。 但是，这些企业有财务能力来支持数字化转型，因为他们知道其规模可带来整体收益。

使用正确的工具 (Use the Right Tools)

If you are into Microservices and Microfrontends, it’s essential to use the right tools and practices.

如果您对微服务和微前端感兴趣，那么使用正确的工具和实践至关重要。

If you are using a public cloud provider, it would be a lifesaver to use the middleware available in the cloud. These will help to reduce the total cost of ownership when using Gateways, Async Communication, Data Storage, Monitoring for Microservices.

如果您使用的是公共云提供商，那么使用云中可用的中间件将是一个救星。 这些将有助于减少使用网关，异步通信，数据存储，微服务监控时的总体拥有成本。

Similarly, if you adopt Microfrontends along the way, you can use Bit (Github) for sharing and managing independent UI components. It will also improve your overall developer experience (DX) by handling the DevOps complexities around independent components.

同样，如果您一路采用Microfrontends，则可以使用Bit ( Github )共享和管理独立的UI组件。 通过处理围绕独立组件的DevOps复杂性，还将改善您的总体开发人员体验(DX)。

Besides, its important to structure your projects correctly to improve developer productivity. You can go for either a distributed repository or a monorepo approach, and setup DevOps around the structure for fast releases.

此外，正确构建项目以提高开发人员生产力也很重要。 您可以采用分布式存储库或monorepo方法，并在结构周围设置DevOps以实现快速发布。

概要 (Summary)

Finally, I want to finish this article by saying that be cautious if you decide to follow the Microservices approach from the beginning of a project. The journey seems to be more challenging than you think unless you have a solid case of following Microservices (For example, building an application for a specification or a given standard where you already know the bounded contexts, reducing overall risks). Or else, start with a Monolith.

最后，我想在本文结束时说，如果您决定从项目开始就遵循Microservices方法，请务必谨慎。 除非您有扎实的遵循微服务的案例(例如，在已经知道有限上下文的情况下为规范或给定标准构建应用程序，从而降低总体风险)，否则此过程似乎比您想象的更具挑战性。 否则，从巨型独石开始。

I hope I have made the points clear to you. If you have any questions or don’t agree with the facts, please leave a comment. I would be happy to reply as soon as I can.

希望我已向您阐明了这些要点。 如果您有任何疑问或不同意事实，请发表评论。 我很乐意尽快答复。

学到更多 (Learn More)