mzg9958636
作者mzg99586362017-07-20 13:33
系统工程师, 某银行

成功备战微服务的5个准备步骤

字数 2225阅读 824评论 0赞 0

时至今日,微服务相关的话题不胜枚举,上百次的会议,在线讨论以及相关文章。你可以假设大家已经认识到其优点以及与之俱来的风险。然而,有很多组织没有事先准备就迈入这个潮流了。自然,这也就导致了在架构实现过程中的失败。

  有一位智者曾经说过,“对于商业中所应用的任何技术而言,有2条规则,其一,将自动化应用于高效的运维上才能增加效率;其二,将自动化应用于低效的运维反而会降低效率。”我认为这种哲学对微服务而言亦行之有效。如果你的组织没有为此准备就贸然迁移,很可能会招致失败。以上就是本文的出发点,我将为大家带来在实现微服务架构前需要准备的5个关键步骤。

  1. 从绘图入手

  在开发特定的微服务时,许多开发者都会犯同一个错误:直接写代码。或许,这可能就是你能够犯的最严重的错误了。诚然,对于一个服务而言,你可能会获得成功,但是随着服务数量的上升,所有事情都会变得一团乱。和其它产品一样,它也需要被创造,需要以设计作为初始步骤。将团队汇聚到桌子周围,自由地在纸上(或者白板)绘制服务。首先,找出你所构建的应用的main函数。然后,自顶向下地将它分解成最小单元。最后,找出不同单元的互联通性。这些功能将会成为你的微服务。

20170719020943245.jpg

20170719020943245.jpg

  比如,在一款图书预览应用中,其主要的功能就是比较不同的图书。然而,也有许多其他功能需要开发,例如创建用户履历,评分,评论,图书数据库等。识别每个功能,是将它们转为微服务的关键。

  整个过程将会持续超过一天时间,并且需要多次迭代直至完美。当然,你将需要从许多不同部门的人员手中获得输入,以确保能够知晓其视角和观点,并确保你不会遗漏任何系统功能。

  2. 微服务并不是组织结构

  根据你所在公司的组织结构定义微服务,这似乎是很自然的。如果你正在构建单体(monolithic)应用,这或许真是一个恰当的解决方案。但是,在实现微服务架构时,它可能就是一个错误的决定了。

  也许,这对于销售部门或客户服务是可行的,但是许多组织只有一个部门处理所有的数据库。因此,为所有数据库创建一个微服务将会导致单点故障。而没有单点故障,则是微服务的关键特性之一。

  你希望通过服务实现的一些功能可能会涉及几个组织部门,或者,你可能将会需要为一个部门构建许多微服务。总结一下,你需要将架构聚焦于你想要提供的服务,而非你们公司的组织结构。

  3. 创建合适的组织结构

  转变到一个全然不同的组织架构,能够满足公司在管控活动上变化的需要。之前2个步骤关注于应用的设计,以便能够为最终用户提供正确的功能。现在,是时候确保对于新的架构而言,你拥有恰当的运维支持了。

  你将不得不放弃原有的部门结构,并使团队关注于某个微服务。这意味着这些团队将由拥有不同技能的成员组成,如系统分析师、UX/UI设计师、后端工程师、前端工程师等。如此一来,团队就能够彻底负责它们的项目(微服务)——从开发部署到运维、监控和管理。反过来,由于团队觉得自己拥有这个产品,因此将提升其创建产品的积极性。

ms21.png

ms21.png

  团队的规模视公司/项目的总体人数而定;当然,根据专家的建议,比较理想的规模是每个团队8-10人。和单体架构不同,微服务架构使得你能够根据业务的增长来扩展团队规模。

  当然,所有团队将会(需要)积极配合,以最终促成整个项目。这便是这种结构的主要好处,使我们能够尽可能快地向市场交付产品。

  4. 性能和可靠性同样重要

  切换到微服务架构的整体想法,便是使得创建的最终产品相比于单体应用而言拥有更好的性能,更佳的稳定性(例如,更低的下线风险),同时可以更快地交付市场。将改进性能作为设计的一部分是很重要的,这将确保潜在问题能够尽早被考虑。通常,(性能)问题都源自微服务设计主要考虑功能。然而,如果在更大的服务下,服务崩溃或者变得很慢,那么它就没什么用了。每个服务应该拥有2-3个替代机制,当下层资源失败时,它便可以继续运作。当其中一个机制无法在可接受时间窗口内响应时,服务也需要做到快速切换。

  在前期考虑让服务支持更大的负载变动,你的应用将能够应对实际挑战,你将领先市场,当然这也是你在第一时间考虑切换到微服务的主要原因!

  5. 变更先行

  忽略应用的变化是不切实际的。开发者一直在增加和移除功能,变更代码,替换应用的核心元素等,这在微服务应用中更甚。更确切地说,微服务就是持续演进的。当你每天需要处理多次代码升级时,最好接受一个观点:变更是持续的,而非对于稳定状态的一次偶然性中断。一旦你认知到这一点,你将意识到一开始便整合变更的灵活性需求的重要性。确保应用一直正常工作的一种方式便是准备服务API,这样微服务间便可继续通信,即使它们已被改变。另外,你还需要引入版本控制,以允许服务同时开放新旧接口。另一方面,数据存储的演进是一个更大的挑战。改进数据库模式(schema),使其支持新的功能,传统观点中,这是应用升级时最难处理的部分,微服务并不会使其变得更加简单。然而,单就增加新的域且不破坏现有结构这一点而言,NoSQL数据库会更加灵活。如果你希望你的数据存储需求持续演进(谁不希望呢?),那么你应该将可演化的数据存储作为微服务设计的努力方向之一。

  在迁移到微服务架构时,做适当的准备是整个项目成功的关键因素,这一点我们可以认同。只有经过仔细的准备,创新设计思维,并且具备合适的运维和管理结构,你才能收获微服务带来的所有好处!

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

0

添加新评论0 条评论

Ctrl+Enter 发表

作者其他文章

相关文章

相关问题

相关资料

X社区推广