京小东实习记

大家好，我是成都研究院-B2B业务部-交易平台研发部的王梦津

实习了一段时间，之前主要的工作是和导师 （@erp=xingyu19） 一起做630里面供销二期VOP对接的部分，现在呢在做万商平台的M端。

在我看来，主要就是 用别人的服务，再给别人提供服务 ，所以如果让我做技术分享，那么我就谈谈我使用JSF过程中一些粗糙的理解吧。

关于JSF网上有一篇流传很广的原京东架构师章耿写的《服务化框架技术选型与京东JSF解密》

很难受的是，章耿大佬在前言就拍拍我们这些萌新的头，“小朋友，这篇文章不是为现在的你写的，这里不告诉你为什么要服务化哈”。

的确，现在很多东西看不懂，zookeeper的集群怎么弄的，调用链怎么弄的，我都不知道，章耿大佬从架构的角度谈，的确也不是面向萌新的，那么我 今天就从为什么要服务化入手吧 ，我们 从流程入手 ，看看一个provider怎么能到 consumer。

我们可以回想一下自己写的第一个JavaWeb应用，对于多个模块的功能，我们会分成多个应用与后台连接使用。

然而我们的需求会越来越多，这三个应用也会因此承载新的功能， 功能变复杂 的同时，应用之间的 内聚性不可避免地就会下降 。

我们刚开始遇到这种问题的时候，解决方案非常明了，那就是将应用进行一个 量上的扩展 。

这个时候，应用之间的内聚性的要求满足了，但是的新的问题也很明显，多个应用之间存在着同样的服务，我们会CV很多代码， 代码的重复度很高 ，并且会有随之而来的 复杂性扩散 的问题，

想想我们最开始自己写的项目，每个业务自己写SQL，如果我们后期引入了分库分表，每个业务线都需要关注分库分表引入导致的复杂性，这种“业务无关”的复杂性导致业务方被迫升级，显然不是我们想要的。

我们的解决方案是，将 重用的服务单独提取出来一层

有个这个层面的要求以后， 服务化框架 应运而生。

从上面我们不难看出一个完整的服务化框架必需的组成部分

统一的RPC框架

应用层调用服务层的框架

为什么不直接使用HTTP接口呢 主要原因是RPC调用是一个长连接，使用HTTP增加三次握手等的开销对于大规模的系统无法接受。（比如说有次用到@erp=cdshihuifeng提供的发短信的接口就不是JSF调用，我想就是因为发送短信不需要维持一个长连接吧）， 并且服务注册中心可以对调用者监控、下线接口、动态扩展，不会影响调用方。

管理平台

管理调用服务

服务注册中心

注册服务层的对应服务

分布式跟踪 ：调用链模式对服务进行跟踪

网关 ：限流服务 协议转换 统一的鉴权服务 服务测试

接口管理文档 ：展示接口详情

配置中心 ：设置重试次数、超时时间 分组配置 限流 路由策略和黑白名单

监控中心 ：统计服务质量信息

服务治理 ：服务路由 调用授权 动态分组 调用限流 灰度部署 配置下发 服务降级

（这里面很多模块都值得展开来讲，但是我还有很多需要去了解的地方，加上篇幅的限制，我们或许后面有机会再分享吧）

以上，我们解决了为什么要服务化还有一个完整的服务化框架需要哪些组成部分这两个问题。