微服务:优缺点是什么? [英] 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.
弹性工程中的一个关键概念是隔板.如果系统的一个组件失败，但该失败不会级联，您可以隔离问题和其余部分系统可以继续工作.服务边界成为您明显的隔板.在一个单体服务，如果服务失败，一切都会停止工作.带有单体系统，我们可以在多台机器上运行以减少失败的机会，但是微服务，我们可以构建系统来处理服务的全部故障和降级相应的功能.
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!
仅引用 Martin Fowler:
我们听到的一个合理的论点是你不应该从微服务架构.而是从一个整体开始，保持它模块化，一旦单体成为一个问题.
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屋！
