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

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

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

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

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

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

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

微服务不适合所有人

（编辑：西安站长网）

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