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

《成功备战微服务的5个准备步骤》要点：
本文介绍了成功备战微服务的5个准备步骤，希望对您有用。如果有疑问，可以联系我们。

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

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

1. 从绘图入手

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

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

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

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

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

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

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

3. 创建合适的组织结构

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

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

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

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

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

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

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

5. 变更先行

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

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

原文链接：https://dzone.com/articles/5-steps-to-successfully-prepare-for-microservices

文章来自微信公众号：Docker