这是一个革命性的软件时代,我们在构建,部署和使用服务上都发生了巨大变化,这种变化不仅仅是技术上的,也是工作方式上的。 新的规范,模式和技术正在塑造整个行业,我们正在进入一个技术和文化的新时代。 不得不说,开源软件是这种变化的催化剂,在这个时代,它正成为企业采用新规范和架构的主要参与者。
有人建议将单体应用像乐高积木一样进行拆分再重新组合,这是个艰难的过程,因为拆分是痛苦的。这个工作一旦完成,每个独立的部分都有一个特定作用并且能够独立运行;而当所有的部分组合在一起时,它们又能像一个整体一样运行工作。 对于应用程序,这意味着从单个大型代码库拆分成较小的隔离服务,这些服务间能相互通信以提供完整的应用程序功能。同时,你的原来的旧架构的应用可能已经有了流量,所以在重构期间也需要保持现有服务与用户不受影响。
你需要从单体架构转型吗
在决定迁移到微服务之前,我们先来看两个问题:
- 项目的总体目标是什么?
- 项目架构的哪些特征最有助于实现这些目标?
首先我们要明白,微服务架构的优点和缺点同样突出。 对于拥有更短,更集中开发周期的项目,微服务在部署或更新应用程序时提供了更大的灵活性。 这可以明显提高团队的开发效率,因为开发团队可以分解成更小的工作组,各小组可以在项目发展的同时独立工作。 此外,微服务使应用程序更容易被扩展,这一点与现在的云战略是一致的。
尽管微服务架构的某些特性很优秀,我们仍可以考虑保持单体架构。因为即使微服务在整个应用程序的开发和管理中会提供更大的灵活性,这种灵活性也导致我们需要更多的协调和通信机制来部署微服务,它明显增加了项目的复杂性。并且,应用程序的模块过多,也会影响应用程序的性能。MonoLITHic应用由一个代码库组成,因此应用程序性能考虑因素主要来自于开发上;而可广泛分布的微服务为了保证各模块能正常协同工作,对网络通信也提出了更高的要求。但是性能,部署难度和可扩展性才是企业在决定采用微服务架构还是单体架构时需要考虑的更重要因素;毕竟上面提到的只是微服务少数的优点和缺点。
进入微服务的注意事项
我们可以很容易意识到,企业迁移到微服务的一个共同驱动因素是维护MonoLITHic应用的效率非常低。企业对业务敏捷性的追求使得微服务化看起来势在必行,但是,这并不意味着我们能顺利过渡到微服务。
在进入微服务前,我们需要考量以下因素:
1. 业务边界
在开始动手前,最大的痛点是确定代码库中各业务模块的边界,将它们分离为单独的服务。不要在这些服务模块的“大小调整”中投入太多精力,因为大小主要与背后的代码量有关。我们需要关注的是确保这些服务能够在分配的边界内正常处理它们的业务逻辑。分离过程中,开发人员和架构师过于关注代码块的大小也是很常见的。若分得过细,你最终可能会得到很多细碎的模块。但实际上随着你在这个新架构下的迭代和发展,未来总有时间让你进一步解耦服务。
2. 开发安排
还有另一个重要的因素,当您开始转换到微服务时,您现有业务的仍在MonoLITHic应用上运行并增长。我们可以考虑将开发团队分为两个较小的团队:一个维护旧代码库,另一个负责新代码库。因为维护旧应用并不像学习新技术那样令人兴奋,同时因为两队的工作量与工作内容不同可能会引发摩擦。所以我们需要密切关注资源分配,又或者我们可以考虑采取轮换制度,团队成员可以在两个项目之间切换。这样所有团队成员都有机会接触到新技术并获得新技能,同时也能让他们时刻关注着项目的最新进度。
3. 通信方式
除了上面两个因素,还有很重要的一点是思考服务间的通信方式。微服务的通信方式有两种,一种是同步的通信方式,另一种是异步的通信方式。这两种方式的主要区别在于,异步方式的微服务不会直接与另一个微服务进行通信,而是会“异步”传播一个事件,另一个微服务可以拦截和响应该事件。
提交一个新用户的注册请求,这个事务需要调用三个微服务:将用户信息写入数据库、发送注册成功的邮件给用户、开通相应权限。
在上面的例子里,如果微服务采用同步通信,那么当邮件队列阻塞不能发送邮件时,会导致其他两个微服务也无法执行,最终导致用户注册失败。
如果微服务采用异步通信,应用程序将用户注册信息发送给消息队列服务器后立即返回用户注册成功的响应;而记录用户注册信息到数据库、发送用户注册成功邮件、开通用户相应权限这三个微服务分别从消息队列获取用户注册信息来异步执行。这样即使邮件服务队列阻塞,邮件发送失败,也不会影响其他微服务的执行,用户注册操作顺利完成,可能只是晚一点收到注册成功的邮件。
当事务不需要立即响应时,异步通信非常有用。 对于那些必须要确认服务调用成功才能继续下一步操作的事务,则不适合用异步通信。我们应该根据服务性质来判断采用何种通信方式。
[caption id="" aLIgn="aLIgnnone" widTH="634"]
同步通信方式示例[/caption]
[caption id="" aLIgn="aLIgnnone" widTH="638"]
异步通信方式示例[/caption]
过渡到微服务不会在一夜之间发生,它需要一个渐进的过程,我们应该耐心谨慎地应对这一切。
小结
本章我们讨论了从monoLITHic迁移到microservices需要思考的几点问题以及迁移过程中的注意事项。
下一章,我们来谈谈过渡到微服务的策略,以及该过程的最佳实践。