之前讲解了什么是微服务:微服务的核心在于服务治理,微服务架构是将复杂臃肿的单体应用进行细粒度的服务化拆分,每个拆分出来的服务各自独立打包部署,并交由小团队进行开发和运维,从而极大地提高了应用交付的效率。
什么时候进行服务化拆分?拆分单体应用有哪些标准呢?
比如做社交 App,初期为了快速上线,验证可行性,可以只开发首页信息流、评论等基本功能。产品上线后,经过一段时间的运营,用户开始逐步增多,可行性验证通过,下一阶段就需要进一步增加更多的新特性来吸引更多的目标用户,比如再给这个社交 App 添加个人主页显示、消息通知等功能。
这个时候就需要大规模地扩张开发人员,以支撑多个功能的开发。如果这个时候继续采用单体应用架构,多个功能模块混杂在一起开发、测试和部署的话,就会导致不同功能之间相互影响,一次打包部署需要所有的功能都测试 OK 才能上线。而且,多个功能模块混部在一起,对线上服务的稳定性也是个巨大的挑战。
再例举一个 58 到家的例子,随着业务越来越复杂,数据量越来越大,并发量越来越大,15 年的时候,58 到家的架构碰到了种种问题:
这个时候 58 到家开始进行服务化拆分,找到通用痛点,抽象出通用数据访问与子业务,然后将它们下沉成微服务。
一般来说,一旦单体应用同时进行开发的人员超过 10 人,就会遇到上面的问题,这个时候就该考虑进行服务化拆分了。
那么服务化拆分具体该如何实施呢?一个最有效的手段就是将不同的功能模块服务化,独立部署和运维。以前面提到的社交 App 为例,可以认为首页信息流是一个服务,评论是一个服务,消息通知是一个服务,个人主页也是一个服务。
这种服务化拆分方式是纵向拆分,是从业务维度进行拆分。标准是按照业务的关联程度来决定,关联比较密切的业务适合拆分为一个微服务,而功能相对比较独立的业务适合单独拆分为一个微服务。
还有一种服务化拆分方式是横向拆分,是从公共且独立功能维度拆分。标准是按照是否有公共的被多个其他服务调用,且依赖的资源独立不与其他业务耦合。
以前面的社交 App 为例,无论是首页信息流、评论、消息箱还是个人主页,都需要显示用户的昵称。如果把用户的昵称功能单独部署成一个独立的服务,那么有什么变更我只需要上线这个服务即可,其他服务不受影响,开发和上线成本就大大降低了。
一般情况下,业务系统引入新技术就必然会带来架构的复杂度提升,在具体决策前,先要认识到新架构会带来哪些新的问题,这些问题你和你的团队是否能够解决?如何解决?是自己投入人力建设,还是采用业界开源方案?
下面几个问题,是从单体应用迁移到微服务架构时必将面临也必须解决的。
针对上述问题,必须有可行的解决方案之后,才能进行服务化拆分。
无论是纵向拆分还是横向拆分,都是将单体应用庞杂的功能进行拆分,抽离成单独的服务部署。
但并不是功能拆分的越细越好,过度的拆分反而会让服务数量膨胀变得难以管理,因此找到符合自己业务现状和团队人员技术水平的拆分粒度才是可取的。
参考 https://time.geekbang.org/column/article/13891 https://www.infoq.cn/article/2017/09/Do-your-service-first