《金融时报》从单体切换到微服务的经验分享 - Sarah

《金融时报》从单体切换到微服务的经验分享 - Sarah

Sarah莎拉于 2021 年初离开英国《金融时报》，现在写一本关于微服务的书，以传授她在微服务方面的经验和专业知识。具体来说，关于如何成功实施微服务及其组织文化、构建和运营方面。

持续交付：微服务好于单体
金融时报脱离其单体应用的主要原因是发布限制。由于发布可能会冻结网站，发布计划禁止在工作时间发布代码，并将发布时间限制在每月的一个星期六。
对《金融时报》来说，大部分时间是可以的，因为很多都是商业和政治新闻，但当有事情发生，可能会有突发新闻时，这总是一个问题。
更重要的是，新版本发布时会推送大量的代码。同时发布不同功能的新代码，使得我们很难把握是什么原因导致了一个确定的结果，比如阅读时间延长的人数增加或系统的故障。
如果出了问题，就要弄清楚这个版本中的哪些提交是非常困难的，如果你试着和进行代码修改的开发人员交谈，但他们可能是在五六个星期前编写的。

而微服务则允许可靠的、分散的、更短的发布周期，零停机时间，这种能力被称为持续交付。
有了持续交付，他们就能以单体应用所不能的方式进行试验。建立一个 "可能失败的假设"，并看看它对预先确定的指标有什么影响。
 如果它不成功，或者如果它产生了你没有预料到的影响，你就应该撤销它。
由于持续发布优先考虑短的发布周期，请让微服务代码背后的人负责，并限制他们把微服务代码交给不同的团队。
此外，鼓励向团队介绍对应用程序负责的心态：如果它出了问题，他们要负责。她明白这种责任有积极的作用，使开发人员在构建产品时更加谨慎。

当你是一个可能要站起来修复它的人时，你会以不同的方式来构建事物 。

微服务的所有权
依靠一个团队成员的专业知识来构建应用程序可能是有害的，因为他们总是有可能离开公司。
在单体应用中，运维单体的团队应该了解整个事情，而在微服务中，很容易出现这样的情况：每个人都说，'嗯，不，我们不知道这个服务是怎么工作的'"。
为了解决这个难题，她提出了一种她称之为BizOps的所有权：根据这个框架，微服务是由团队而不是个人拥有的。因此，团队将避免依赖个人来使事情顺利进行，而且没有团队成员会垄断产品的所有权。

迁移到微服务
微服务迁移，用较新的软件或混合微服务取代传统单体应用的一部分。
在《金融时报》的迁移案例中，很多从事微服务系统的人都建立了单体
从头开始微服务，而不是从单体应用改编的主要好处是：允许人们专注于新的架构，而不担心 "它与现有的单体如何互动"。

组织微服务
尽管微服务带来了价值，也会带来问题：
 如果你有150个微服务，你要花150倍的时间来做任何你必须为每个服务做的事情。

对她来说，这个问题的答案是自动化。
比如说，你真的想为你的账单管道建立一个模板，这样你就可以在所有的管道中添加一些东西。

另一个制约因素是升级库，特别是许多微服务使用的库。
在这种情况下，别无选择，只能繁琐地搜索资源库。通过根据系统的不同部分使用不同的数据存储，找到了解决方案。尽管如此，这种解决方案也有一个缺点。

保持微服务的更新对团队的要求很高，所以必须意识到微服务的权衡，才能使用它们。

另一种组织微服务的形式是通过集群，微服务集群是囊括所有注定属于某个领域或任务的服务的理想选择：在Sarah的案例中，有一个用于内容发布平台的集群，总共有一组服务，我们称之为会员平台，这都是与能够订阅和访问内容有关的。然而，这些都需要有相当明确的界限，只有一组微服务是自然地适合放在一起。

采用新技术
尽管微服务提供了与不同技术合作的可能性，但在采用这些技术时也有一些限制。首先是安全限制。

你拥有的东西越多，你的风险就越大，你的潜在成本就越高，这取决于成本如何运作。

第二，运维困难。如果所有的东西都是不同的，那么当出现问题时，任何人介入并提供帮助有多困难？。不同的技术阻止了在团队之间移动服务的灵活性。

为了面对这些挑战，莎拉提出了护栏的想法。守护线要求开发人员有一套明确的目标，同时，如果开发人员想尝试不同的方法或技术，他们要负责在需要时在规定的时间内进行修补。

banq：微服务是打土豪分田地，土地都已经变成微服务分给一个个程序员了，不要再试图以”上帝“思维或主语思维 将它们统管起来，让”看不见的手“去调节，当然这对主管来说增加不确定性，不确定是这个行业最大特点，是快速发展更换的特点。