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

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

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

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

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

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

微服务的缺点

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

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

当将整体分解为微服务时，将冒着一个非常分散的系统风险，开发人员需要花费大量的时间和精力将服务和工具粘合在一起，并且缺乏可以跨项目工作的常见模式和平台 。为了真正利用微服务，需要能够构建可以实现一键设置的“胶水”供应商。”

(迁移到微服务，通常为带来了大量运维挑战，因为集成和维护很多不同服务的基础设施责任落在了IT团队)

LAMP堆栈的出现可以作为一个很好的对比。Linux、Apache web服务器、MySQL和 PHP等免费工具为web开发开辟了新的可能性。但当公司围绕WordPress、Drupal和Joomla等项目构建集成工具时，LAMP体系结构才真正起飞。

在真正的微服务方法中，团队只运行他们需要的小服务，而不运行其它任何负载。但是，这种实施和编配工作已经超出了许多中小型组织的工程范围。将一个整体分割成许多更小的、独立的服务在速度和敏捷性方面有许多优势，但也有许多挑战。微服务架构可以增加支持和维护的运营开销，因为每个服务都有自己的语言和要求。这也使得监控和安全性变得更加复杂，因此需要更高水平的自动化和工具。而且由于服务之间的通信现在通过网络进行，因此它会对服务发现、消息传递、缓存和容错产生新的要求，这些要求可能会给系统带来压力，如果处理不当可能会导致性能问题。虽然Service Mesh解决了许多这样的问题，但是引入一个没有流量管理的Service Mesh服务，它自己就会产生一些问题，这些问题可能会导致更严重的性能问题。

可以提前做所有想做的测试，并且这会对要发布的代码相当有信心。但是当真正把它投入生产时，就会遇到各种各样的问题，因为实际上并不知道代码在生产中会如何表现。流量管理实际上是将部署与发布解耦。部署是指拥有新代码、新版本并将其投入生产，但还不占用任何客户流量。可以做烟雾测试、内部测试，这些测试都在生产中运行。当发布一个版本时，就会开始思考：要给这个新版本的代码带来什么样的流量?如果有能力把流量控制到非常精细的水平的话，可以分割、控制、并逐步推出新的代码更改。

没有工程资源或技能将稳定的基础架构与现有的开源代码和工具结合在一起的组织，很难 让微服务的好处大于挑战。操作和性能问题也可能困扰那些没有就其服务(依赖关系和版本兼容性)进行沟通的团队，并且必须在生产失败时撤回已经写入的代码。幸运的是，微服务市场正在起飞。许多公司现在不仅生产微服务本身，还生产无缝连接它们所需的平台、工具和框架。

微服务不适合所有人

（编辑：ASP站长网）