云原生时代的微服务，适合所有人么？

通过使小型自治团队能够独立开发，部署和扩展各自的服务，微服务基本上可以并行化开发 ——从而以指数方式加速生产周期。这种敏捷性是大型企业在多种报告中指出采用微服务所引用的首要原因，其次是改进的可扩展性。

微服务可以让开发人员不必浪费时间重新解决已经解决的技术问题。持续集成和部署基本上构建在微服务架构中。微服务可以直接把很多基础设施风险带出项目。随着基础设施变得几乎不可见，微服务团队可以进行通常以小时周期运行的快速迭代，从而持续降低错误功能的风险，同时增加价值。

换句话说，使用微服务，团队中的每个开发人员都可以忘记底层基础设施，专注于自己的项目。然后在生产中，如果单个项目模块不能完全正确地工作在一起，那么很容易对它们进行隔离、拆卸和重新配置，直到正确地工作为止。这些组件是松耦合的，就像乐高一样。这种方式提供了使用可互换的部件在应用程序体系结构中大规模运行的能力。它们的独立和独立结构也带来了安全性优势，因为更容易通过自动化和实施安全策略的现代安全平台进行控制。

随着组织的发展，工程团队可以更轻松地扩展和维持速度。微服务架构的主要好处不是技术，而在于团队开发和人员管理。相比之下，当代码库增长到一定规模时，单体应用程序变得无法适应和管理。管理这种规模的应用程序架构的团队绝不能让单体架构失效。如果整体架构失效了，那么业务也会随之流失。因此编写脚本以防止应用程序泄漏并在主要版本升级之间构建各种补丁成为企业架构师的重要优先事项。功能是预先定义好的，并按照优先级与整体相适应;客户则被夹在中间，并且做出的强制性决策可能是短期的解决方法，但会带来较长期的问题，例如定制化的脚本随着时间推移而失效，并且依赖于具有企业基础架构记忆的人员。这本身是一个糟糕的体验，因为新的软件升级可能无法解决客户遇到的问题。

一个主要问题是(单体)应用程序会变得极其复杂。它太大了，任何单个开发人员都无法完全理解。因此修复bug和正确实现新特性将变得困难且费时。更重要的是，这是一个恶性循环。如果代码库难以理解，那么将无法正确进行更改。许多组织已经达到了这样一个阶段，即管理单体应用整体结构的痛苦超过了采用新的微服务方法。微服务的采用是这类组织的优秀选择，尽管它也有自己的挑战。

微服务的缺点

微服务是经典单体应用的对立面，具有明显的优势。但是，与任何正在发展的技术一样，早期采用曲线可能很陡峭。目前，Netflix和PayPal等大公司最有效地采用了这种方法，由于强大的内部资源和工程团队，这些公司已经能够转向微服务架构。

Netlify首席执行官兼联合创始人Mathias Biilmann表示:“当你拥有一个非常庞大、资源丰富的企业，个人团队能够管理每项服务并确保可重用性和可探索性时，这是非常棒的。”然而，对于其他人来说，痛苦是真实存在的。根据有关报告，只有1%的企业使用微服务表示他们对架构没有任何挑战。操作开销、日志记录和监视方面的挑战以及缺乏技能被列为最主要的挑战。离开单一的应用程序体系结构意味着失去将所有部分粘合在一起的固定工作流。最常见的情况是，因为IT团队主要负责集成和维护许多不同服务的基础设施，采用微服务体系结构会增加操作成本。团队必须在微服务远景与实际需要之间艰难地找到平衡，才能使其发挥作用并取得成功。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!