翻译一张大神的图片
图片地址：
https://github.com/dwmkerr/blog/blob/master/articles/2018/microservice-madness/images/questions.png
图片内容：
图片翻译：
[1.Team Size]
can you fit your team around a large table?
yes: You might not need microservices yet(challenges around deployment, development, operations etc can probably be most easily handled by good communication and good design - microservices may be a solution to a problem you are not really suffering from.)
no: Microservices might help you(if your team is large, or you have many teams, you might not be able to enforce strong boundaries between components with good design alone. enforcing boundaries by separating components into isolated services may help.)
[1.团队规模]
你能让你的团队围成一张大桌子吗?
是的:您可能还不需要微服务(围绕部署、开发、操作等方面的挑战可能最容易通过良好的沟通和良好的设计来处理——微服务可能是您并不真正遇到的问题的解决方案)。
不:微服务可能会帮助您(如果您的团队很大，或者您有很多团队，那么您可能无法仅通过良好的设计来强制组件之间的强边界。通过将组件分离为独立的服务来加强边界可能会有所帮助。)
[2.State]
are you dealing with a primarily stateless system?
yes: consider serverless(If you are mostly stateless, you may be able to skip microservices and go straight to serverless, at least for parts of your system.)
no: microservices will come with complexity(This doesn't mean don't use microservices, but be aware that they will not be trivial to implement of manage, particularly as the system changes over time.)
[2.状态]
您正在处理的主要是无状态系统吗?
是的:考虑使用无服务器(如果您基本上是无状态的，那么您可以跳过微服务，直接使用无服务器，至少对于系统的某些部分是这样)。
不:微服务将带来复杂性(这并不意味着不使用微服务，但要注意，它们的实现和管理并不简单，特别是随着时间的推移，系统会发生变化)。
[3.Consumers]
are you building a solution for a single app or service?
yes: be careful - might have fuzzy domains(if everything you are building is for a single comsumer, you may find that when you build features, you might be updating many services at once. Microservices might be valid, but be extremely carefull in how you design you domains)
no: microservices may be very valuable(if you are designing for many diverse consumers, microservices may be a very sensible pattern to look into, to allow you to bring new features to new consumers quickly)
[3.消费者]
您正在为单个应用程序或服务构建解决方案吗?
是的:小心-可能有模糊的域(如果您正在构建的所有东西都是针对单个消费者的，那么您可能会发现，当您构建特性时，您可能同时更新许多服务。微服务可能是有效的，但在如何设计域时要特别小心)
不:微服务可能非常有价值(如果您为许多不同的消费者进行设计，那么微服务可能是一种非常明智的模式，可以让您快速为新消费者带来新功能)
[4.Dependencies]
do you have monolithic dependencies?
yes: performance might be an issue(independently scalable services are unlikely to be a benefit in this case, as you are dependent on the performance of your dependencies. so some of the key benefits may be unacheivable. you might also have less well defined boundaries to your services.)
no: microservices may be very valuable(if you are not constrained by monoliths downstream, you might be able to achieve th high degree of independence required for effective scaling of microservices)
[4.依赖关系]
您有独立的依赖关系吗?
是的:性能可能是个问题(在这种情况下，独立的可伸缩服务不太可能带来好处，因为依赖于依赖项的性能。因此，一些关键的好处可能是无法实现的。您的服务可能也没有很好的定义边界。)
不:微服务可能非常有价值(如果您不受下游巨石的限制，您可能能够实现有效扩展微服务所需的高度独立性)
[5.Expertise]
got container / orchestration / devops experts?
yes: microservices may be very valuable(if you've got the chops, it might be worth looking into microservices, you have the skills to deal with the complexities which will arise and can probably capatalise on the benefits)
no: consider testing the water first(if you don't have the expertise, or are already struggling with devops, this might be to much of a jump. perhaps consider a small simple service as a spike or proof of concept. learn the skills on projects which are not mission-critical first)
[5.专业知识]
有容器/编制/ devops专家吗?
是的:微服务可能非常有价值(如果你有能力，那就值得研究一下微服务，你有能力处理将会出现的复杂问题，并且很有可能从中获益)
不可以:考虑先测试水(如果您没有相关的专业知识，或者已经在与devops做斗争，那么这可能是一个很大的飞跃。也许可以将一个简单的小服务看作是概念的一个尖峰或证明。(首先要学习任务无关紧要的项目的技能)