江苏龙网

  1. 首页 > 资讯 > 科技 > >

技术编程|5个规则，确保你的微服务优化运行( 二 )


挑战3：部署一项服务会破坏另一项服务
单片机世界中的一个关键假设是 ， 所有代码都是在同一时间部署的 ， 这意味着应用程序处于最脆弱状态的时间范围是一个已知的、相对较短的时间段（即部署后的前24-48小时） 。 在微服务的世界里 ， 这个假设不再成立：由于微服务本质上是相互交织的 ， 其中一个服务细微的变更可能会导致行为或性能问题 ， 而这些问题会在另一个服务中体现出来 。 因此所面临的挑战是 ， 当前出现故障的微服务使得另一个开发团队并没有预料到他们的代码会出现中断 。 这既会导致整个应用意外的不稳定性 ， 也会导致一些组织内部的摩擦 。 虽然微服务架构可能让部署代码的过程变得更容易 ， 但实际上却让部署后验证代码行为的过程变得更难 。
解决方案
企业必须创建共享的发布日历 ， 并且每当部署相关的微服务时 ， 都要分配资源用于密切测试和监控整个应用的行为 。 在没有跨团队协调的情况下部署新版本的微服务 ， 就像牛油果加吐司一样 ， 是解决这一挑战的成功秘诀 。
挑战4：难以找到问题的根本原因
在这一点上 ， 你已经锁定了有问题的服务 ， 提取了所有需要提取的数据 ， 包括堆栈跟踪和日志中的一些变量值 。 你可能还有一些APM解决方案 ， 比如New Relic、AppDynamics或Dynatrace 。 从那里 ， 你会得到一些额外的数据 ， 关于一些相关方法的异常高处理时间 。 但是......问题的根本原因呢？
你（希望）从日志中得到的前几位变量数据很可能不会是那些移动针的数据 。 它们通常更像是面包屑 ， 指向下一条线索的方向 ， 而不是更进一步的原因 。 在这一点上 ， 我们需要尽我们所能 ， 发掘出更多应用程序下的 "魔力" 。 传统上 ， 这需要发出关于每个失败事务状态的详细信息（即到底为什么失败） 。 这里的挑战是 ， 需要开发人员具有巨大的预见性 ， 以知道他们需要哪些信息来提前排除问题 。
解决方案
当微服务中的错误根源横跨多个服务时 ， 制定一个集中的问题根源检测方法至关重要 。 团队必须考虑需要哪些信息颗粒来诊断未来的问题 ， 以及它们应该在什么层级上发出日志 ， 以考虑到性能和安全因素——这是一座高高的山 ， 而且是一座永无止境的山 。
挑战5：版本管理
我们认为值得强调的问题是 ， 从典型的单体架构中的层模型过渡到微服务的图模型 。 由于超过80％的应用程序代码通常是第三方代码 ， 因此在公司的不同微服务之间管理第三方代码的共享方式成为避免陷入前所未有的“依赖地狱”的关键因素 。
考虑这样一种情况：一些团队在使用第三方组件或共享实例程序的X.Y版本（几乎所有公司都有） ， 而其他团队则使用X.Z版本 。 这就增加了由于不同版本之间缺乏兼容性而产生的关键软件问题的风险 ， 或者说 ， 不同版本之间行为的轻微变化 ， 可能会导致需要排查最特异和痛苦的软件bug 。
而在这一切之前 ， 我们还要提醒自己 ， 任何一个微服务使用第三方代码的旧版本、更脆弱的版本 ， 都会产生安全问题——这是黑客的天堂 。 允许不同的团队在孤岛般的repo中管理他们的依赖性 ， 在单体世界中可能是可行的 ， 但在微服务架构中 ， 这是绝对不可以的 。
解决方案
公司必须在重新设计他们的构建流程方面进行投资 ， 以便为第三方和共享实用程序代码利用集中式artifact仓库（Artifactory将是其中之一） 。 团队应该只允许将自己的代码存储在单独的仓库中 。
最后的思考
【技术编程|5个规则，确保你的微服务优化运行】与科技行业的大多数进步一样 ， 微服务采用了一个熟悉的概念 ， 并将其颠覆 。 它们重新思考了大规模应用的设计、构建和维护方式 。 它们带来了许多好处 ， 但也带来了新的挑战 。 当我们把这五个主要挑战放在一起看时 ， 我们可以看到它们都源于同一个理念 。 因此 ， 每当采用像微服务这样的新技术时 ， 底线是既需要重新思考 ， 也需要重新调整代码的构建、部署和观察方式 。 微服务所带来的优势是难以拒绝的——但风险也是巨大的 。


推荐阅读


上一篇：电脑使用技巧|受够了慢成龟速的游戏读条时间？试试加块固态硬盘，结局就会不一样

下一篇：|今日推荐 | 牛市或已悄然开启，那么这次距离顶峰有多远？又会持续多久？