解决方案
企业必须创建共享的发布日历，并且每当部署相关的微服务时，都要分配资源用于密切测试和监控整个应用的行为 。在没有跨团队协调的情况下部署新版本的微服务，就像牛油果加吐司一样，是解决这一挑战的成功秘诀 。
挑战4：难以找到问题的根本原因在这一点上，你已经锁定了有问题的服务，提取了所有需要提取的数据，包括堆栈跟踪和日志中的一些变量值 。你可能还有一些APM解决方案，比如New Relic、AppDynamics或Dynatrace 。从那里，你会得到一些额外的数据，关于一些相关方法的异常高处理时间 。但是......问题的根本原因呢？
你（希望）从日志中得到的前几位变量数据很可能不会是那些移动针的数据 。它们通常更像是面包屑，指向下一条线索的方向，而不是更进一步的原因 。在这一点上，我们需要尽我们所能，发掘出更多应用程序下的 "魔力" 。传统上，这需要发出关于每个失败事务状态的详细信息（即到底为什么失败） 。这里的挑战是，需要开发人员具有巨大的预见性，以知道他们需要哪些信息来提前排除问题 。
解决方案
当微服务中的错误根源横跨多个服务时，制定一个集中的问题根源检测方法至关重要 。团队必须考虑需要哪些信息颗粒来诊断未来的问题，以及它们应该在什么层级上发出日志，以考虑到性能和安全因素——这是一座高高的山，而且是一座永无止境的山 。
挑战5：版本管理我们认为值得强调的问题是，从典型的单体架构中的层模型过渡到微服务的图模型 。由于超过80％的应用程序代码通常是第三方代码，因此在公司的不同微服务之间管理第三方代码的共享方式成为避免陷入前所未有的“依赖地狱”的关键因素 。
考虑这样一种情况：一些团队在使用第三方组件或共享实例程序的X.Y版本（几乎所有公司都有），而其他团队则使用X.Z版本 。这就增加了由于不同版本之间缺乏兼容性而产生的关键软件问题的风险，或者说，不同版本之间行为的轻微变化，可能会导致需要排查最特异和痛苦的软件bug 。
而在这一切之前，我们还要提醒自己，任何一个微服务使用第三方代码的旧版本、更脆弱的版本，都会产生安全问题——这是黑客的天堂 。允许不同的团队在孤岛般的repo中管理他们的依赖性，在单体世界中可能是可行的，但在微服务架构中，这是绝对不可以的 。
解决方案
公司必须在重新设计他们的构建流程方面进行投资，以便为第三方和共享实用程序代码利用集中式artifact仓库（Artifactory将是其中之一） 。团队应该只允许将自己的代码存储在单独的仓库中 。
最后的思考与科技行业的大多数进步一样，微服务采用了一个熟悉的概念，并将其颠覆 。它们重新思考了大规模应用的设计、构建和维护方式 。它们带来了许多好处，但也带来了新的挑战 。当我们把这五个主要挑战放在一起看时，我们可以看到它们都源于同一个理念 。因此，每当采用像微服务这样的新技术时，底线是既需要重新思考，也需要重新调整代码的构建、部署和观察方式 。微服务所带来的优势是难以拒绝的——但风险也是巨大的 。
【5个规则，确保你的微服务优化运行】
推荐阅读
- 美工包月，淘宝美工让设计有“秩序感”的5个技巧
- 自媒体写作，如何产出超多爆款文章？教你5个爆文选择方法
- 10个隐藏极深的小米手机技巧，知道5个以上，算是元老级别的米粉
- 何为MySQL 字符集和校验规则（ CHARSET & COLLATE)？
- 英雄联盟特权服务15个皮肤有哪些？
- 下个月起正式实施，机动车迎来5个好消息
- 如何防治冬季咳嗽？不妨试试5个偏方
- 魔法骑士桌游具体规则
- 淘宝迟延发货赔偿 淘宝延迟发货赔偿规则最新规则
- 淘宝代付规则 淘宝代付有时间限制吗