几周前，我写了这篇文章：
对我来说，这是一种新的写作方式，我只是想用它来测试。 从那时起，它就一直成为我有史以来最受欢迎的帖子之一，而最近的忙碌活动促使我撰写了故事的第二部分。
故事发生在高级开发人员Gemma的领导下，她领导着她公司的团队并朝着基于微服务的架构迈进。 这个故事发生在她的团队过渡到基于微服务的架构的三个月后。
路上的颠簸
总体而言，向微服务架构的过渡已证明对公司有利。 Gemma成功地设计了一种解决方案，将网站分为3个不同的问题域。 帐户服务，商店服务和漫画阅读器服务。
减少停机时间
投产3个月后，漫画公司的停机时间已经结束，这在一定程度上要归功于其蓝绿色的部署策略。 不再有发生“大爆炸”部署且随后死亡的情况，整个站点都将瘫痪。
通过进行蓝绿色部署，Gemma和她的团队能够将其系统的新版本与现有的稳定发行版一起部署，并执行多种不同的测试，例如金丝雀测试，以确保当他们进行最终转换时，一切正常名义上。
部署困难
但是，随着Gemma和她的团队转向基于微服务的方法时，他们发现花在部署上的时间增加了。
他们不再执行单一应用程序的“一个”发布，而是每次执行发布时都在部署2到6个不同的服务。 这包括其3个服务中每一个的新的绿蓝色实例。
这显然不是理想的，因为他们在减少停机时间和增强架构方面获得了好处，而在开发人员生产力方面却失去了。 作为一个小型团队，如果每3天将一名开发人员拖入价值4个小时的部署中，那实际上就会开始损害团队的生产力。
Kubernetes的崛起
遇到这个绊脚石之后，Gemma被迫进行进一步研究，并找到一种可以自动发布的方式，以便他们可以收回浪费的时间并更加专注于提供关键业务价值。
这是她发现Kubernetes的时候。 她看了一下《 Kubernetes：启动和运行》，并开始精通使用Kubernetes的艺术。
Kubernetes本质上允许她和她的团队做的就是将整个系统定义为代码。 在AWS的新托管Kubernetes服务之上运行此程序，这使他们在管理整体资产方面节省了很多时间。
提出的唯一问题是，团队需要一些时间来学习托管Kubernetes服务和基础Kubernetes 技术的来龙去脉。 随着时间的流逝，这将进一步节省成本，Gemma对此没有任何问题。
可追溯性的损失
转移到基于微服务的体系结构时出现的另一个有点麻烦的问题是关于出了什么问题的可追溯性的损失。
随着任何应用程序中服务数量的增长，能够跨构建该应用程序的各种微服务跟踪请求变得很麻烦。
如果其中一项服务出现问题，他们如何在容易调用的所有后续系统中进行跟踪？
最初，效率低下的调试机制浪费了很多时间。 每次在周末遇到问题时，工程师都会被召唤，他们会讨厌在线并尝试调试发生的事情。 即使遇到非问题，任何面临的问题都需要花费至少一个小时来调试。
可追溯性的答案：Zipkin
Gemma转向了一个名为Zipkin的系统，该系统基于Google自己的跟踪系统Dapper的构想。 Zipkin本质上为您提供了所有服务间呼叫的非常详细的跟踪，并且本质上使Gemma及其团队能够跟踪其服务中面临的所有问题。
再一次，必须花更多的时间来学习这个新工具，并确保其团队中的所有开发人员都对使用该工具进行有效调试感到满意。
但是，一旦他们熟悉Zipkin，他们便能够利用这些非常棒的外观呼叫跟踪。
3个月后—结论
转向基于微服务的架构6个月后，团队在更改速度方面看到了巨大的进步。
他们在弹性方面取得了巨大的进步，客户体验得到了极大的改善。 他们能够快速部署用户喜欢的更改和改进，并且整个公司能够在在线漫画市场上占据主导地位。
团队花了很多时间来学习新技术，但是最初投入的时间最终才带来真正的红利。
结论
希望您发现这篇后续文章与上一篇文章一样具有娱乐性和启发性。 与往常一样，如果您想对我的写作风格有任何反馈，请告诉我！ 我一直渴望改善表达观点的方式！
我想讲这个故事的寓意是，尽管基于分布式微服务的体系结构可能适用于大多数不同的系统和团队结构，但您确实必须考虑部署和可跟踪性等方面的复杂性增加。 与以前的方式相比，这是一个巨大的改变，嵌入在其整体方式中的开发人员的心态将不得不改变。
想与我联系吗？ 随意发推文@ Elliot Forbes 。
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
