首先本文不讨论为什么要服务化,包括服务化的优点缺点。
其次本文也不讨论什么是微服务,也不讨论微服务和SOA的区别。
最后本文也不讨论哪个技术最优。
基本的服务化框架包括如下模块:统一的RPC框架,服务注册中心,管理平台。
有了这三个模块,就能实现基本的服务化。下面对三个模块进行具体分析。
为什么一定要是统一的RPC框架,而不是随便啥框架,这里主要是为了技术对齐,减少开发人员的学习成本,减少团队间沟通成本。
好,那么选择一个RPC框架,我们都需要考量什么东西呢?这里我总结下:
另外如果是从开源里面选择,那么我们还需要考量:
下面是常见的一些开源框架的比较,大家可以看一下。
Ps:SOAP,RMI,Hessian,ICE就不列举了。
注册中心相当于是服务提供者和服务调用者之间的引路人,在服务治理中的作用极为重要。
选择注册中心基本要考量:
重点提一下这个状态检测,因为这个要是检测不准确会误判,导致严重后果,
例如Zookeeper根据服务端注册的临时节点进行状态检测,如果服务端和Zookeeper之间的网络闪断,导致Zookeeper认为服务端已经死了,从而摘掉这个节点。
但是其实客户端和服务端直接的网络是好的,这样就有可能把节点全部摘掉,导致无可用节点。
如果是从开源里面选择,那么还需要考量:
下面是常见的一些使用开源项目做注册中心的比较,大家可以看一下。
Ps:Redis和MySQL没有列举。
管理端没啥特殊要求,最起码能看到服务提供者和调用者即可。
如果需要一个完善的服务化框架,那么必须增加外部模块,常见的模块如下图:
提供一个接口文档管理以及接口查询的入口,可以是一个公共的WIKI,也可以是独立的系统,等等。
这里可以定义接口的文档,包括接口描述,方法定义,字段定义
可以定义接口的SLA,包括支持的并发数,tp99多少,建议配置是什么
还有就是接口的负责人等一些查询的入口。
提供一个配置管理的地方,这里说的配置主要指的是服务相关的一些配置。
配置包括分组配置、路由策略、黑白名单、降级开关、限流信息、超时时间、重试次数等等,任何可以动态变更的所有数据。
这样服务提供者和服务调用者可以不需要重启自己的应用,直接进行配置的变更。
配置中心可以独立于注册中心,也可以和注册中心合并。
监控服务关注接口维度,实例(例如所在JVM实例)维度的数据。
RPC框架可以定时上报调用次数,耗时,异常等信息。
监控中心可以统计出服务质量信息,也可以进行监控报警。
区别于监控中心,以调用链的模式对服务进行。
RPC框架作为分布式跟踪系统的一个天然埋点,可以很好的进行一个数据输出。
我这边列了常见的服务治理功能,例如:
服务路由:
调用授权:
动态分组:
调用限流:
灰度部署:
配置下发:
服务降级:
RPC框架大部分场景都是自己调用的,什么时候会需要一个网关呢?
网关可以提供如下功能:
其它一些统一处理逻辑(例如请求解析,响应包装)
需要逻辑处理能力,例如对数据进行筛选过滤整合,计算服务路由等功能
同时还需要有与RPC框架交互的功能。
管理端除了之前的简单服务管理功能外,还需要提供配置信息展示,监控信息展示,各种维度的数据展示。
也就是下面提到的服务治理功能,都可以在管理端进行管理。
另外,常见的服务治理功能,我们都可以作为开放服务供开发人员进行一个调用。
2012年初,京东从.NET转Java。各个部门,各个业务线都没有一个统一的服务化框架,有的是dubbo,有的是WebService,有的是Hessian等等。
同时各个业务系统自己有非常多的业务代码。通过统计接口规模在1K左右,服务节点在50K左右,机器规模在8K左右,机房比较少拓扑简单。
所以当时的愿景和目标比较明确:
OK,结合我们的情况和上面的一些选型小结,我们当时的选择如下:
于2012年4月上线,最大规模时,接口数3K,接入最大IP数20K。
随着京东业务的不断快速增长,接口、机器数也呈数量级增长。
同时京东成立子公司,在全国各地新建机房,部署结构也变得比较复杂。
加上SAF遗留的一些问题,大概面临如下几点:
所以在2014年初,我们进行了第二代JSF的一个全部自研过程。
我们主要做了如下技术选型:(全部自研)
开发周期:7人/年(2014.1-2015.1)。包括开发、测试、预发、上线、推广。
京东的注册中心是自研的,基于DB做的数据最终一致,也就是上面说的AP系统。
注册中心主要实现的就是服务列表的注册订阅推送,服务配置的获取下发,服务状态的实时查看等功能。
注册中心节点是无状态的,可水平扩展的。整个注册中心集群下的所有注册中心几点都是等价的。
每个机房部署多个注册中心节点。同机房的RPC框架会优先连本机房的注册中心节点。
主要亮点如下:
引入Index服务概念
注册中心内存有服务列表全量缓存,连不上数据库也保证可读
数据库的数据结构更适合各种维度展示、过滤、分析等
RPC框架作为服务化里面的最基本的组件,其实都大同小异,因为RPC调用都绕不开代理、网络、序列化这些操作。
JSF的RPC框架也类似,主要分为图中的几个模块,
下面大概列下一些功能特性:
提供强大管理功能,包括服务管理,监控管理,注册中心管理等功能。
我们针对服务治理的功能,提供了很多API,可以授权给开发人员或者外部系统使用。
例如单元测试调用,限流配置/开关,动态分组,上下线等都提供了开放API。
网关是为了方便跨语言通过HTTP+JSON调用JSF服务,而不需要使用JSF的RPC框架。
特性如下:
基于Netty4.0实现HTTP网关,没有使用Servlet容器,轻量高效。
支持服务自动发现
京东的JSF服务开发在京东弹性云的研发推广之前完成,自从京东弹性云落地以来,也遇到不少问题。
例如:
意思就是不要人云亦云,盲目看大公司用什么,现在什么最新,或者什么性能最好。因为架构不是让你一下子设计出来使用一辈子,好的架构都是慢慢演化而来的。不同的架构会做出不同的技术选型。所以无论什么时候都要结合自己的现状以及未来几年的规划,来进行技术选型。
服务化框架的选择只是开始,真正的变革是选择后,公司整体业务和开发的变革。这个大家有空可以看看康威定律。