洋码头系统架构技术解读

系统架构

架构1.0

在2013年初，洋码头的技术团队只有20人，洋码头当时的技术表现形式类似一个传统的PC电商网站。然而随着APP形态的大热，业务形态快速从传统的PC网站向APP发展升级。在这样的场景下，由于之前二、三年代码堆砌下，洋码头的应用已经很臃肿，开发人员都在抱怨编译慢，系统模块也不能重用。最初级形态的系统架构就这样自然的发生了，技术团队开始对应用进行拆站、组件化和服务化工作，并制订了最初的主站架构蓝图。从最复杂最核心的订单交易业务开始，把订单交易相关的代码拆分出来，快速封装成一个restful风格的服务，供各端调用;然后将活动站、商品模块、列表、搜索等开发内容拆分，不再共享同一个应用，使得开发效率有了一定的提升。

经过上述改造，这个架构迎来了初次的业务高峰，并成功接受了第一次交易峰值的洗礼。虽然从现在来看那个峰值并不高，而且这种拆分还是相当简单粗暴的，有很多后遗症，但是从当时的人力情况来说，这个方案快速的解决了重用业务逻辑和开发效率的问题，有效的支持了当时的业务能继续高效发展。

缓存、消息队列、微服务

在第一次的架构图设计完成之后，洋码头开始有了专职的架构师，并完成了几个非常关键的开发工作：

商品服务重构引入了redis缓存方案;

引入了分布式消息队列RabbitMQ，基于开源框架二次开发了一套事件总线的架构，一定程度上解决了当时各系统之间的集成问题;

核心交易下沉为独立的服务，基于事件机制，快速与包括商品、活动、库存等模块进行集成;

从单一的PC网站，转变为同时面向PC、手机APP、手机WAP等多元化业务生态系统。

同时，线上环境的服务器资源进行了数倍的扩张，有效的缓解了线上系统的访问压力瓶颈。不过业务的复杂性是递增的，扩容只能解决单点的性能问题，没有合理的架构，单纯靠物理硬件的投入是不可能长期支持业务的爆发式增长的。而且多个敏捷小团队并行开发，版本合并、回归测试等等耗时耗力的任务仍然严重的影响着业务功能的快速交付。服务化势在必行。当时正值微服务大热，技术团队对服务拆分改造热情高涨，陆续将下单、购物车、优惠券、库存、限购策略、红包等业务的服务拆分，分由不同的团队开发和维护，从原本的版本合并完成后两周发一次版本，变成一天几十个服务分头发版上线，大大提高了并行开发效率。

数据库优化和分离

在性能上，这个时期设计的商品浏览、价格、库存、活动信息等大部分都是直接读取数据库，内部又包含了大量的join，性能很差，经常性地把主数据库的IO/CPU等瞬间拉高，并导致其他应用受到影响。当时的解决方案是不光从硬件上投入更好的资源，同时单独启用MongoDB集群对只读业务进行分离，将相关信息使用消息总线的方式近实时的同步过去，这样分拆后查询效率得到极大的提高，并达成了初步的读写分离。

消息总线

随着服务化的推进，系统间的关系越来越复杂，迫切需要一个异步处理框架来解决系统间解耦，异步调用的问题。随之架构团队启动了第一代消息总线服务，采用RabbitMQ作为消息中间件。定义了一套restful风格的标准的消息发送和消费接口，这样各业务系统就像调用普通的服务接口一样调用消息总线，没有任何负担;同时消费端也不需要关心消息中间件怎么用，只需要提供一个webAPI接口就行，总线自动会分发到各订阅站。这大大简化了异步系统的开发。很多业务系统(包括我们大量需要双写的系统)都接入了消息总线，使之成为整个电商系统不可或缺的一部分。

但是第一代的消息总线存在一些不太好解决的问题，比如客户端发送失败怎么办，RabbitMQ脑裂导致消息消费时丢失怎么办?吞吐量特别高的时候，比如用户认证消息，批量发送用户营销消息，RabbitMQ的性能可能不够。架构团队很快又启动第二代消息总线的重构，通过总线客户端MQ组件内嵌内部数据库的方式解决发送失败重试的问题，针对关键消息引入mongoDB二级存储，在中间件出问题的时候，可以通过DB进行补单，甚至在两种存储都出问题的时候，还可以通过服务端本地文件队列维持消息总线的正常运行。同时针对大批量的数据分发业务，引入Kafka来解决问题。通过后台配置，可以在两种存储之间进行切换。

转型JAVA

2016年起技术团队决定技术平台转型试点，从.NET逐步转到java平台，线上服务越来越多，迫切需要一个服务框架来治理这些服务。那个时候springboot、springclound刚刚起步还未流行起来，技术团队选择了业界比较成熟的dubbox,可以同时支持dubbo协议和基于http的json协议，该框架自带服务注册和发现，同时通过客户端组件进行服务调用的负载均衡，实现了P2P的服务调用，不再依赖中间代理服务器。目前大部分核心服务都已经完成了基于dubbox的微服务改造，系统的性能有了明显的提升，部分.NET业务开始试点.NETCORE。

自研开源分支

在架构不断演化升级的今天，洋码头架构团队根据业务场景需要，已经先后开发推出了多个重磅级产品，包括根据开源系统定制的洋码头分支disconfY和DubboY，消息总线服务、高性能高可用的RPC框架、统一后台和批处理调度服务、计数服务等。在业务和应用架构方向，对系统做了多重拆分方案，将应用层和服务层分离，基础服务独立出来并可复用，对独立的业务进行了垂直切分。明确了服务化方案，对各服务提供的接口进行了整理规范，细化了服务的职责。技术架构决定了可以支撑的业务高度。洋码头这几年来在技术架构上的持续构建和优化逐渐展现威力，近几年多次大促中业务系统稳定流畅的表现便是最好的注解。