本次分享的技术大纲如下:
- 传统应用开发面临的挑战
- 服务化实践
- 服务化不是银弹
- 服务化架构的演进方向
一 、传统应用开发面临的挑战
挑战1-- 研发成本高
主要体现在如下几个方面:
- 代码重复率高
在实际项目分工时,开发都是各自负责几个功能,即便开发之间存在功能重叠,往往也会选择自己实现,而不是类库共享,主要原因如下:
- 从技术架构角度看,传统垂直架构的特点是本地API接口调用,不存在业务的拆分和互相调用,使用到什么功能就本地开发,非常方便,不需要过度依赖于其它功能模块;
- 从考核角度来看,共享很难推行。开发只需要对自己开发的模块交付质量负责,没有义务为他人提供并维护公共类库,这个非常耗费成本;
- 时间依赖很难把控:对于公共类库的使用者而言,依赖别人提供此功能,但是功能提供者可能有更重要的事情在做,提供时间无法满足使用者。与其坐等别人提供,还不如自己开发效率高;
跨地域、跨开发小组协调很困难,业务团队可能跨地域研发,内部通常也会分成多个开发小组,各开发小组之间的协调和沟通成本非常高。
- 需求变更困难
代码重复率变高之后,已有功能变更或者新需求加入都会非常困难,以充值缴费功能为例,不同的充值渠道开发了相同的限额保护功能,当限额保护功能发生变更之后,所有重复开发的限额保护功能都需要重新修改和测试,很容易出现修改不一致或者被遗漏,导致部分渠道充值功能正常,部分存在Bug的问题,示例如下:
- 无法满足新业务快速创新和敏捷交付
挑战2-- 运维效率低
在传统的MVC架构中,业务流程是由一长串本地接口或者方法调用串联起来的,臃肿而冗长,而且往往由一个人负责开发和维护。随着业务的发展和需求变化,本地代码在不断的迭代和变更,最后形成了一个个垂直的功能孤岛,只有原来的开发者才理解接口调用关系和功能需求,一旦原有的开发者离职或者调到其他项目组,这些功能模块的运维就会变得非常困难:
当垂直应用越来越多时,连架构师都无法描述应用间的架构关系,随着业务的发展和功能膨胀,这种架构很容易发生腐化。
- 测试、部署成本高:业务运行在一个进程中,因此系统中任何程序的改变,都需要对整个系统重新测试并部署
- 可伸缩性差:水平扩展只能基于整个系统进行扩展,无法针对某一个功能模块按需扩展
- 可靠性差:某个应用BUG,例如死循环、OOM等,会导致整个进程宕机,影响其它合设的应用
如何解决传统单体架构面临的挑战?
解决对策:1、拆分 2、解耦 3、透明 4、独立 5、分层。
- 拆分:对应用进行水平和垂直拆分,例如商品中心、计费中心、订单中心等。
- 解耦:通过服务化和订阅、发布机制对应用调用关系解耦,支持服务的自动注册和发现
- 透明:通过服务注册中心管理服务的发布和消费、调用关系
- 独立:服务可以独立打包、发布、部署、启停、扩容和升级,核心服务独立集群部署
- 分层:梳理和抽取核心应用、公共应用,作为独立的服务下沉到核心和公共能力层,逐渐形成稳定的服务中心,使前端应用能更快速的响应多变的市场需求
二、服务化实践
服务的订阅发布机制
它的核心理念是实现服务消费者和服务提供者的解耦,让服务消费者能够像使用本地接口一样消费远端的服务提供者,而不需要关心服务提供者的位置信息,实现透明化调用。
关键技术点:服务的订阅、发布机制、服务的健康状态检测和高HA。
常用的服务注册中心有Zookeeper、ETCD,以及基于数据库的配置中心。
大家在技术选型的时候,需要根据自己的业务实际情况进行选择。例如超大规模集群,服务实例数超过10W,Zookeeper就会存在性能问题。
现在开源的分布式配置服务很多,如无特殊需求,建议选择开源方案。
服务化实践-零侵入
实际上,完全的零侵入很难做到,即使是