京东中间件应用实战

       在互联网应用研发过程中，中间件扮演着极其重要角色，因为数据存取、服务划分、消息传递、负载均衡、DNS、CDN等等。

       中间件在互联网应用开发中有着重要作用，其中以微服务、数据存取、消息队列三大中间件最为重要。

       微服务，最早程序研发是一个大的整体，存在问题研发困难，困难主要表现在修改后程序容易导致其他模块不可用，单体程序还存在一个流量预估难题，平时还好电商大促流量突增，单体程序流量预估难度极大，而微服务一下子将问题简化多个量级，只要预估好每个人维护微服务程序就可以了。

       JD微服务是自己研发框架，与dubbo相比整个架构设计紧凑简洁，dubbo相比设计扩展性强，各有优劣。核心差异不大，线上有个大流量服务大促时6000万/分钟，100万qps 150台4核16G容器。dubbo是阿里开源好东西，对业界微服务化极大推动，感谢开源，dubbo能够支持千万级、亿级每分钟掉用量处理，是极其优秀框架，最近又重启更新，需要用到微服务的可以放心用起来。

       微服务本身客户端实现软负载均衡，节省大量硬件作为负载均衡使用，缺点也是有的，微服务横向扩展容易，纵向也能够方便分层，但尽量不能分太多层，因为每层均存在网络耗时。

       记得app首页入口图初版服务，单个容器规格4核8G内存50G硬盘，但个容器能处理请求10万/分钟，而且还可以加量继续压，轻轻松松完成c100k处理。

       数据存取，存储读取是应用程序永恒主题，分布式缓存redis这篇文章介绍过大型电商互联网架构中redis运用，redis内存缓存是快，天下武功唯快不破，但是内存目前还是极其昂贵资源，分布式文件系统，Google大数据三架马车之一bigtable，能支撑Google搜索引擎对于网页存储与检索，感兴趣也可进行研究使用，遗憾是google未开源，但百度开源了分布式文件系统BFS对应HDFS、以及分布式数据库TERA对应bigtable，据官方公开文档查询性能在10ms以下，进行参数设置性能能到1ms。

       消息队列，消息队列在为复杂程序节藕，大公司不同部门系统、模块之间数据通讯，移动端数据上报等多个重要流程，均离不开他，在数据通讯传输占有核心地位。

       清晰记得新浪微博，在初期有一段时间点赞时响应极其慢，最尴尬的事还经常失败，用户体验极差，简直让用户抓狂，后来看到网上分享了解到是因为点赞包含多个流程，在原微博上点赞加一，在自己用户上增加和这条微博点赞关系，权重计算处权重加一用于微博feed分发这条用等等逻辑，再一次需要全走完非常慢，用消息队列节藕，点赞发消息就可以给客户端反馈成功，性能呈指数级提升，各个模块取消息进行消费处理进行相应操作就可以了，用户体验极大提升。

       对于数据交互通信场景，了解到大数据那块数据分两块一个是离线hive表交乎一个是读取mysql或提供微服务拉取数据交互，有前边这些还不够，因为又个需要及时增删改场景就需要消息队列进行处理，比如评论或问答用户回答质量差这时就需要，删除消息将质量差评论、问答删除掉。对了目前各大互联网公司用的比较多消息队列是Kafka以及ActiveMQ。

       数据上报场景，移动时代数据点击、浏览、GMV、转化率等各个指标都离不开数据埋点上报，个性化推荐系统特征工程中数据汇总上报也离不开消息队列，上报流程一般是Storm实施消费消息数据落到大数据HDFS、HBase等。这个过程中消息队列都是必不可少的。

       互联网公司中间件占有重要地位，对于应用快速开发，数据稳定访问，数据上报等，服务高性能、高可用发挥着重要作用。中间件之中又以服务划分、服务治理，数据存取，消息队列中间件最为重要。

        其他中间件，例如JD本身有自己研发UMP能方便监控应用性能、可用率、容器cpu、内存、线程等多个指标，开源比如性能监控有大众点评CAT。再有智能DNS、CDN、负载均衡lvs、haproxy等等中间件也在互联网架构中发挥这重要作用。

        容器本身在JD也发挥着重要作用，线上服务100%在容器中，大数据spark那些据了解也在容器化进行中。以docker代表容器化技术，cpu、内存隔离性好，网络吞吐也极高，是一种极其优秀技术。

       docker目前存在问题，大促时有些个别机器，它的服务cpu、内存占用过高影响其他容器里面服务，这种情况备战期间要仔细观察，尽量和负载高应用避开，这种问题个人看到占比极其小，容器技术在互联网公司目前发挥着重要作用。

        写出来记录一下，一是为后续查找方便，另外如果对读者如果遇到相应问题正在一筹莫展，文章如果能带来一些启发那就更好了。