云计算·大数据 频道

微服务架构重构是怎样一种“神仙体验”?

  如今,很多企业都在进行微服务架构重构,问题是微服务到底是不是一个恰当的选择?如果选择没有问题,微服务在什么时候用?重构之后的技术路线和之前是怎样一种关系?我们应该以什么样的方式,把之前和之后的技术结合起来……相信,这些都是很多开发者在微服务重构过程中,必然会遇到的问题。

  在笔者看来,企业在部署架构的时候,看似是遇到问题,解决问题, 但其实要秉承一个原则,那就是“以始为终”,在开始出发前就要知道终点在哪里。具体到微服务架构重构,根本目的是要解决当前架构的问题,最终能让系统支撑业务高质量发展。

  重构不可避免

  首先,开发者需要明确的一点是,重构不可避免。不管是复杂的应用系统,还是任意一个APP,甚至是类似于office这样的软件,都有自己的生命周期。在漫长的生命周期里,业务和需求都在不断变化,最后的需求和最开始的设计,已经完全不一样,当系统现状和大家的认知有严重冲突的时候,不重构系统,软件就难以继续维护开发下去。另外,技术开发本身也在不断变化,比如:在代码层需要不断引入新代码,加入了很多冗余的内容,变得僵硬、脆弱、难以维护,需要开发周期越来越长,Bug越来越多,所以重构成为必然结果。

  以具体微服务实践为例,随着长时间、多地辗转,功能越做越大,已经没人了解最初的设计思路和项目初衷;但有一个有意思的现象是,大家在开发新功能的时候,都喜欢把功能放在这个微服务里,开发迭代速度逐渐变慢,Bug环比稳中有升。换言之,随着功能的增加,该微服务退化成了单体架构。

  虽然,我们今天都在谈微服务,但其实不管是单体架构还是微服务,都各有优缺点。比如:单体架构虽然不够灵活,但好处是紧凑,你想要什么变量,直接调用对象就可以了,内存是共享状态,使得功能开发变得简单。既然这样,为什么要重构呢?答案是,业务发展是最大推动力!当业务方准备进行一次较大规模的新业务尝试,新业务形式上有很大变化,不过核心业务功能变化不大,但研究团队发现服务复用很困难。

  用领域驱动设计驱动系统重构

  那么,我们到底以什么样的方式去设计我们的系统?

  、

  当项目简单的时候,有两种开发方式:一种是CRUD Design,增删改查,有什么做什么;另一种Domain Driven Design,就是我们常说的DDD领域驱动设计。项目简单的时候,CRUD开发成本更低,而DDD设计模式需要把业务领域分析清楚以后,做合适的服务分析,做合适的对象设计,进而通过合适的领域设计去完成。

  值得一提的是,CRUD和DDD会有一个交叉点,而业务最终的演进方向一定会向复杂的方向发展。尤其是互联网项目,开始只是做一些简单的业务逻辑实现,之后随着业务的发展,会变得越来越复杂,传统开发方式就会变得艰难。

  所以,在使用微服务之前,一定不要指望微服务能做什么,微服务不是灵丹妙药,也不是尚方宝剑,不能解决一切问题。

  微服务重构复盘

  通过微服务进行系统重构,大概需要六个步骤:

  第一,把当前系统设计与问题汇总讨论。比如:架构与代码混乱,需求迭代困难,部署麻烦,Bug频率逐渐升高等等,都汇总在一起。

  第二,针对问题分析具体原因。微服务A太庞大,微服务B和C职责不清,团队内业务理解不一致,内部代码设计不良,硬编码和耦合太多……寻找这些问题的具体原因。

  第三,重新梳理业务流程,明确业务术语,进行DDD战略设计。比如:活动图,子域分解,限界上下文设计等等,理解这些专业用语,用于战略设计。

  第四,针对当前系统实现和DDD设计不匹配的地方设计微服务重构方案。

  第五,DDD战术设计与技术验证,比如:聚合、实体、值对象设计、打样代码开发。

  第六,任务分解与持续重构,在不影响业务开发的前提下,按照战略与战术设计,将重构开发和业务迭代有机结合。

  需要重点强调的是,不管是微服务,还是单体服务,任何技术都一样,都是解决特定问题的一个具体方法。而其中,微服务的正确解法是,先分析问题,再找合适的方案。大体来看,微服务的真正难点不是技术,而是业务。技术问题解决起来非常容易,但业务问题不好梳理。企业需要先解决业务问题,重新梳理业务,再找合适的工具和方法。

0
相关文章