币创网分布式系统架构揭秘

 　　基础架构：整套系统依托于阿里云企业级互联网架构解决方案，使用到的服务包括：EDSA + HSF + MQ + RDS + REDIS + SLB + VPC + CDN + OSS + MAIL + SMS。

　　架构图

　　1、使用了加速乐提供的防DDOS，防CC，WAF整套安全方案。

　　2、主站依托于负载均衡，CDN加速，动静分离，EDAS动态扩容，缓解主站访问压力。

　　3、后端服务依托HSF和MQ解耦。

　　4、数据库层面依托DDRS中间件和TXC分布式事务解决数据库层面的设计和压力。

　　5、使用了阿里提供的邮件推送，短信服务，语音服务。

　　为何选择EDAS

　　框架选择

　　dubbo/dubbox：国内开源产品Top5，企业最常用的SOA框架。

　　SpringCloud：Spring官方背书的分布式系统构建工具集。

　　HSF : 阿里现役分布式服务开发框架。

　　语言选择

　　Golang ： Google出品的系统级语言，天生高并发。

　　Java : 企业级开发首选，轮子众多。

　　内部基础工具几乎都是Go编写，唯一的问题就是需要团队自行开发很多基础设施来维系整个架构。

　　相比较而言，SpringCloud目前势头很好，非常看好，应用目前较少。dubbo/dubbox国内使用很多，开发人员也比较好招，我们立项初期首选。

　　HSF作为阿里内部现役并且淘汰Dubbo的分布式开发框架，配置上结构上和Dubbo有很多相似地方，开发人员学习成本不大。引用一段介绍：

　　HSF采用软件实现负载均衡，支持随机、轮询、权重、按应用路由等方式。软件负载均衡没有中间点，通过配置中心统一管理。配置中心收集服务提供者和消费者的注册信息，以推送的方式发送到服务消费者直接使用，不经过中间点;注册中心可以感应服务器的状态，出现failover时，实现注册信息重新推送。

　　还有一个更大的亮点，阿里云推出的PaaS平台EDAS，引用阿里云相关介绍：

　　初遇EDAS当时选择EDAS唯一的痛点在于资料很少，但还是掩盖不了EDAS的光芒，阿里背书，十年考验，更重要的是可以帮助技术团队把除代码开发外的工作全包揽了，减轻了整个团队基础设施的搭建和运维的很多工作。

　　阿里云依托内部技术输出，提供完整解决方案这一步棋走的非常明智，向中小企业提供完整解决方案帮助上云，互赢互利。

　　搭建交易平台真正的挑战在于考虑代码层面的架构外还要充分考虑平台的基础设施和应用监控，高可用，高容错，弹性伸缩，运维平台搭建，风控机制等。

　　问题来了，一系列的配套是需要开发团队拿时间去完善的，但是我们的理念和发展方向，决定了开发团队在立项初期要兼顾开发速度和后期扩展以及整个基础设施的完善。

　　技术框架选型初期，阿里的企业互联网架构解决方案正在主推，阿里内部输出了很多优秀并且经过考验的中间件，Paas平台EDAS，消息队列，数据库中间件DRDS，分布式任务调度，分布式事务。这些中间件解决了很多初创技术团队的痛点和难点，提供了搭建服务的便利性和可靠性，这也是我们选择阿里云的最大原因。PS：当时最吸引我的是EDAS一篇关于中石化易派客构建的文章，大概的意思就是“只要你易派客的业务量超过不了阿里，保你不出问题”!

　　选定框架初期，EDAS的文档不够详细，控制台还老出问题。印象最深的就是凌晨4点开始部署上线的时候，控制台创建不了应用...

　　在四处找文档，疯狂提工单的情况下，项目进展飞快，技术团队只要保证业务的独立性，可扩展性就没问题。

　　EDAS的一个特点是基础监控和性能监控，服务版本的发布，回滚，Beta测试，减少了初创公司运维和基础实施搭建的难度，其实币创的开发理念迎合了EDAS的特性，专心于业务。

　　服务组成

　　所有服务均可以弹性伸缩，保证业务的稳定增长。

　　用户服务

　　涉及到用户基础操作，安全相关操作，行为日志记录。

　　用户资金服务

　　用户前台资产操作，强一致性事务保证。

　　委单服务

　　收集用户订单，归纳，投递行情服务。

　　行情服务

　　收集相关订单状态信息，负责行情，深度等平台实时信息生成。

　　活动服务

　　针对网站的活动统一归类。

　　撮合服务

　　负责平台币种的撮合业务。

　　安全

　　安全对于交易所是第一道屏障，也是保护用户资产安全的重要手段。

　　主站和APP均经过专业渗透测试，开发人员并针对进行了升级防护。

　　加速乐为网站提供全方位军工级防护体系。

　　在虚拟币安全存储方面采用了冷热钱包分离和内网隔离来保护用户资金安全。

　　好的架构是进化而来的

　　微服务和SOA是讨论很火热的一对CP。话说，如果计算机性能无上限的话，也没这哥俩了。分布式出现的原由也是单台服务器出现了性能瓶颈，需要拆分。

　　架构初期币创选择了微服务模式，理想很丰满，但是时间，人员上带来了很大的挑战，项目进展很慢，也很困惑，经过几次的讨论，修正，决定不去刻意选择，微到什么地步也不去刻意思考。保证可动态弹性伸缩，高可用即可。

　　抛开业务谈架构谈模式纯属耍流氓，不要一上来就拿着几编文章，别人怎么叭叭叭...

　　适合团队，适合业务，一定量的代码耦合可以承受，保证代码基础的可读性，接口化，独立性就可以。我们技术团队有强制规定，注释，代码格式，代码不美观等要做俯卧撑。这样的前提下，技术团队只要考虑定点打围就好，压力点来了拆分业务即可。

　　切记，依据团队，依据业务，好的架构是根据公司的成长，业务的增多而进化的。

　　撮合引擎难点

　　开发撮合引擎过程中，着重几个点分享一下。

　　1.撮合业务逻辑并不复杂，难点在对撮合业务的微拆分和订单状态的细分处理。

　　2.针对于订单的状态，共享场景不多，切记要根据业务模型区分订单状态。

　　坑

　　EDAS创建应用成功，部署失败的情况，请查看日志目录是否有Tomcat目录，没有的话果断删除应用重建。

　　SLB对于健康检查失败的端口是会屏蔽访问的，可自行关闭对应检查。

　　阿里的消息队列(MQ)是为“最终一致性”而生，针对不具备幂等性的业务要处理。

　　特别注意阿里云有些业务是后付费，账户内一定要保留足够资金。

　　“寄予”

　　交易所除了架构层面之外，还有核心的业务逻辑，风控体系，存储安全，财务体系等都是交易所要面临到的难点，接下来会不定期分享币创针对这些难点的处理方案和实践经验。

　　作者：王卓超(币创网技术总监、系统架构师)