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

22-09-11 banq

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

1