微服务:优点和缺点是什么? [英] Microservices: what are pros and cons?
问题描述
与替代架构相比，使用微服务的优缺点是什么? 使用微服务时有经验法则吗?
What are pros and cons of using microservices in comparison with alternative architectures? Is there a rule of thumb when microservices should be used?
推荐答案
优点
Sam Newman在构建微服务中，列举了微服务的主要优点如下:
Pros
Sam Newman in Building Microservices, enumerates the key benefits of Microservices as following:
在一个由多个协作服务组成的系统中，我们可以决定使用不同的 每个内部的技术.这使我们能够为每个工作选择合适的工具，而不是 必须选择一种更加标准化的，一刀切"的方法，而这种方法常常最终被 最低的公分母.
With a system composed of multiple, collaborating services, we can decide to use different technologies inside each one. This allows us to pick the right tool for each job, rather than having to select a more standardized, one-size-fits-all approach that often ends up being the lowest common denominator.
弹性工程中的关键概念是 bulkhead .如果系统的一个组成部分 失败，但是这种失败并没有级联，您可以找出问题所在，其余的 系统可以进行工作.服务边界成为您显而易见的隔壁.在一个 整体服务，如果服务失败，一切都会停止.与单片 系统，我们可以在多台机器上运行以减少发生故障的机会，但是 微服务，我们可以构建处理服务全部失败并降级的系统 功能.
A key concept in resilience engineering is the bulkhead. If one component of a system fails, but that failure doesn’t cascade, you can isolate the problem and the rest of the system can carry on working. Service boundaries become your obvious bulkheads. In a monolithic service, if the service fails, everything stops working. With a monolithic system, we can run on multiple machines to reduce our chance of failure, but with microservices, we can build systems that handle the total failure of services and degrade functionality accordingly.
借助大型的整体服务，我们必须将所有内容一起扩展.一小部分 我们整个系统的性能都受到限制，但是如果该行为被锁定在 巨大的整体应用程序，我们必须将所有内容按比例缩放处理.和 较小的服务，我们可以扩展那些需要扩展的服务，从而使我们能够运行 系统的其他部分则安装在体积较小，功能较弱的硬件上.
With a large, monolithic service, we have to scale everything together. One small part of our overall system is constrained in performance, but if that behavior is locked up in a giant monolithic application, we have to handle scaling everything as a piece. With smaller services, we can just scale those services that need scaling, allowing us to run other parts of the system on smaller, less powerful hardware.
将单行更改为一百万行的整体应用程序需要整体 为了发布更改而部署的应用程序.这可能会产生很大的影响， 高风险部署.在实践中，最终会发生影响大，风险高的部署 由于可理解的恐惧而很少出现.
A one-line change to a million-line-long monolithic application requires the whole application to be deployed in order to release the change. That could be a large-impact, high-risk deployment. In practice, large-impact, high-risk deployments end up happening infrequently due to understandable fear.
借助微服务，我们可以更改单个服务并独立部署 该系统的其余部分.这使我们能够更快地部署代码.如果有问题 发生时，可以快速将其隔离到单个服务，从而使快速回滚易于实现 实现.
With microservices, we can make a change to a single service and deploy it independently of the rest of the system. This allows us to get our code deployed faster. If a problem does occur, it can be isolated quickly to an individual service, making fast rollback easy to achieve.
微服务使我们能够更好地将架构与组织相结合，从而帮助我们 最小化在任何一个代码库上工作的人员数量，以达到团队的最佳位置 规模和生产力.我们还可以在团队之间转移服务所有权，以保持 在同一服务上工作的人们.
Microservices allow us to better align our architecture to our organization, helping us minimize the number of people working on any one codebase to hit the sweet spot of team size and productivity. We can also shift ownership of services between teams to try to keep people working on one service colocated.
分布式系统和面向服务的体系结构的主要承诺之一是 我们为功能复用提供了机会.借助微服务，我们允许 为不同目的而以不同方式使用的功能.这可以是 当我们考虑消费者如何使用我们的软件时，这一点尤其重要.
One of the key promises of distributed systems and service-oriented architectures is that we open up opportunities for reuse of functionality. With microservices, we allow for our functionality to be consumed in different ways for different purposes. This can be especially important when we think about how our consumers use our software.
如果您在中型或大型组织中工作，那么您可能会意识到一些 坐在角落的庞大，令人讨厌的旧系统.一个没人想碰的人.那一个 对于公司的运营至关重要，但这恰好是用一些奇怪的Fortran编写的 变体，并且只能在25年前使用寿命终止的硬件上运行.为什么没有 被替换了吗?您知道为什么:这太大了，而且工作风险很大.
If you work at a medium-size or bigger organization, chances are you are aware of some big, nasty legacy system sitting in the corner. The one no one wants to touch. The one that is vital to how your company runs, but that happens to be written in some odd Fortran variant and runs only on hardware that reached end of life 25 years ago. Why hasn’t it been replaced? You know why: it’s too big and risky a job.
由于我们的单个服务规模较小，因此以更好的价格替换它们的成本 实施，甚至完全删除它们，都更易于管理.
With our individual services being small in size, the cost to replace them with a better implementation, or even delete them altogether, is much easier to manage.
微服务的最重要缺点是它们具有以下所有相关的复杂性: 分布式系统，虽然我们已经学到了很多有关如何管理分布式系统的知识 系统很好，仍然很难.如果你要来 从整体系统的角度来看，您必须在处理方面做得更好 部署，测试和监视以释放收益.你会 还需要以不同的方式考虑如何扩展系统并确保它们 有弹性的.如果发生分布式交易或 CAP定理之类的事情，也不要感到惊讶 要么开始让您头痛！
The most important disadvantage of Microservices is that they have all the associated complexities of distributed systems, and while we have learned a lot about how to manage distributed systems well it is still hard. If you’re coming from a monolithic system point of view, you’ll have to get much better at handling deployment, testing, and monitoring to unlock the benefits. You’ll also need to think differently about how you scale your systems and ensure that they are resilient. Don’t also be surprised if things like distributed transactions or CAP theorem start giving you headaches, either!
只需引述马丁·福勒:
我们听到的一个合理论点是，您不应该以 微服务架构.而是从整体开始，保留它 模块化，并在整体组件成为一个整体后将其拆分为微服务 问题.
One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.
这篇关于微服务:优点和缺点是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
