京东、宅急送的微服务实践分享（一）.docxVIP

京东、宅急送的微服务实践共享（一） **** 京东章耿 大家好，我是京东基础架构部平台两头件的章耿，次要担任京东的服务框架，配置中心等项目。京东 2021 年底进行 .NET 转 Java 的技术变革，当时就提出了接口的 SOA 化的概念。那时京东业务进展格外快，项目越来越多，服务化是必定的趋势。 京东的服务化框架是一共有两代。第一代是 2021 年开头，我们使用开源的一个实现，用 Dubbo 作为 RPC 框架，Zookeeper 作为注册中心，那时应当算一个主流的技术选型。我们在开源的基础上做了一些易用性和功能扩展，比如说支持 REST、支持 kryo/thrift 等序列化，服务监控等，这个框架在那时的业务规模和节点数量下面还是比较稳定的。 2021 年初我们开头自研服务框架。为什么这么做呢？一个是之前的服务框架还是有很多可以提升的地方，不管是功能还是服务管理的一些功能，由于京东的机器数，机房也在不停的建，网络拓扑的简单直接需要高级的服务管理功能；还有一个就是接口节点等数量级的添加，当时我们的接口规模渐渐的已经好几千了，接口的实例也几十万；另外就是用开源的有些内部系统打通比较麻烦，所以我们要做升级换代。当时也是考量了用开源的改改，还是全部本人重新做的选择。后来觉得一个是有时间，二是觉得本人有力量做一个符合京东本人的定制化的服务框架，所以 2021 年我们就开头自研框架，做了整整一年。2021 年初我们上线新版的服务框架。 我们新的注册中心，是无形态的一些节点，基于数据库做最终全都性。为什么选数据库，替换以前的 Zookeeper？由于 Zookeeper 是树状结构，从某些维度查询它要遍历整棵数，用数据库的好处就是可以从多维度的查询分析过滤，不管是机房、 IP，都可以去查询，分析，过滤比较结果。然后 Zookeeper 在跨机房的时候有一个问题，它是半数节点存活才可以用，所以假如跨机房部署的话，最最少得 3 个机房，才能保证集群全体可用。还有 Zookeeper 它是强全都性的的，比较依靠网络。假如网络不好，假如跨机房断网的时候，它其实是不行用的，读都不能读，所以会带来肯定的问题。以前用 Zookeeper 注册服务端，就是写一个临季节点，等服务端死了节点自动消逝的。但是你在网络抖动的时候，或者是服务端和 Zookeeper 之间有网络毛病的时候，它其实会不当心把它摘掉，由于 Zookeeper 认为它死了，但其实它不肯定真的死了，所以这个时候就需要有一些协助的去推断它是不是真的死了。 第一次遇到的情况是那个临季节点，后来我们是把它改成永久节点，然后定时的去 telnet 它的端口，像 Dubbo 是直执行 ls 命令，我们也是直接执行一个命令，看它有没有响应，那是第一代的时候。在 JSF 的框架里有一个哨兵的组件，我们的 Provider 会定时的发心跳，对于注册中心来说，它晓得最终的心跳时间，然后定时刷到数据库里面，看哨兵的情况，假如没有哨兵，数据库里面保存一个最终心跳时间，这时候你可以用定时任务去找它，这是我们最早的一个版本。 后来我们改进了，由于有时断网了，这个心跳时间就不准了。所以在每个机房还布了一套独立的程序，没心跳的同时再由它来推断能否可用，假如这个同机房的程序都连不上，我们再把它置成一个不行用的形态，双重保证。另外以前 Zookeeper 的时候服务列表是下发的全量列表，例如 1000 台加一台，下发的是 1001 台，而新版注册中心我们是推变化的部分，只推加 1 台，大大节省了数据的推送量。 RPC 框架，我们内部叫杰夫，JSF，京东服务框架的简称。我们是用基于 Netty 本人研发的。为了兼容上一代版本，兼容之前的 dubbo 协议，所以我们也是用的无代码入侵的；我们在同一个端口支持多协议，包括自定义的 JSF 协议，http 协议，dubbo 协议等。目前我们只要 C++ 和 Java 的客户端，然后假如是其它言语例如 Golang，Python，PHP 的话，我们都会让他向我们的一个 HTTP 的网关发恳求，这个网关次要就是转发。把前面的 http 恳求转换到后面一个 JSF 恳求，也是基于 Netty 做的。序列化默认是 Message Pack，是个跨言语的协议，也支持 Hessian，Json，Java，Protobuf 等。注册中心和 RPC 框架直接是长连接，可以进行一个通讯。 宅急送石廷鑫 大家好，我是石廷鑫，原来在京东、唯品会，现在在宅急送。我基本上都是在仓储物流这方面。以前在亚洲一号是依据仓库的整个操作细节分成各个模块来做的服务拆分，每个模块是单独部署的。仓储的每个仓，依据种品类不一样，整个的操作流程是不一样的。但是核心的东西，如库存、订单管理，都是一样的，只是一些组合不一样。举个