交易平台的架构演变及并行化实践

[pengjunlong]

http://www.infoq.com/cn/presentations/trading-platform-architecture-evolution-and-parallel-practice http://doc.mbalib.com/view/80aeda2b02af51a69476307c02b37263.html

[pengjunlong]

系统复杂度：=远程调用（多，不可靠）+容错+体验 从单体应用演进到分布式应用，仍存在问题 新的想法/需求能够尽快在线上落地，交易系统变化快，需要快速交付 下单系统复杂，远程调用之前都是串行，外部依赖越来越多，响应时间越来越长，导致用户体验下降——评估外部依赖关系，做并行调用 全链路系统监控，优雅降级，高并发如七夕业务高峰时如何弹性保护系统，不出现雪崩

多终端支撑问题： pc、客户端前端应用承载太多业务逻辑，mt、dp不同版本客户端 新的业务落地需要多个团队配合；各端能力不一样，经常出现客户端上线了pc需要屏蔽，如果沟通不到位，pc不屏蔽，下单就出错了

业务复杂度： 作为一个业务平台，我们怎么能够快速支持一个业务的快速变化 新的业务需求来时，技术评估来评估去，认为改造成本太大了；没有办法快速定位需要在哪些地方做改动，很难确保我们评估的改动点是否全了

[pengjunlong]

业务规则的位置比较散乱，比如是否支持使用积分、是否有凭证、发什么样的凭证，都是耦合在订单代码逻辑里 业务规则在各服务没有明确的界限 最前端只关注交互和视觉这部分东西，不存在任何业务逻辑；前后端通过规范好的json数据模型做交互 应用层识别哪些是业务规则，哪些是功能，把功能通过组件化抽象出来，有些功能可能有些经常变化的点，每个场景有不同的功能扩展点，来支持业务快速接入，如买家资格校验，哪些买家不能下单，或者针对什么样的商品、什么样的渠道他不能做购买 一个业务可能涉及多个功能点，如涉及用户检查、菜单、优惠计算等功能点，通过java package组成业务套件，组合一些功能点；通过新建package或者remove 一个package

把服务层和业务规则剥离，

[pengjunlong]

解决上一个模型下不同团队对于业务规则理解落地有差别的问题 把业务规则单独出来一层——业务核心 DSL描述在不同服务中有什么定制点，规范服务提供者接口规范（能力提供出来，定制机制提供出来，如价格API接口能指定使用哪一种价格模型），使用集中管控，保证全链路交易规则统一，不会因为理解不一致导致线上资金损失 在交易框架里，通过领域模型能够把不同的规则适配起来，再支持一个新业务，只需要注册到交易框架里，测试框架输出就ok

[pengjunlong]

视图作用：交易比较复杂，能够从不同切面理解这个系统，在每个切面上我们关注哪些点

[pengjunlong]

将架构设计活动精简为以下三个层面

业务架构——根据业务需求设计业务模块及其关系 系统架构——设计系统和子系统的模块 技术架构——决定采用的技术及框架

[pengjunlong]

https://mp.weixin.qq.com/s/jMWuMuIvI1cFThC-WQGbHQ DDD的核心诉求就是将业务架构映射到系统架构上，在响应业务变化调整业务架构时，也随之变化系统架构。而微服务追求业务层面的复用，设计出来的系统架构和业务一致；在技术架构上则系统模块之间充分解耦，可以自由地选择合适的技术架构，去中心化地治理技术和数据。

设计领域模型的一般步骤如下：

根据需求划分出初步的领域和限界上下文，以及上下文之间的关系；

进一步分析每个上下文内部，识别出哪些是实体，哪些是值对象；

对实体、值对象进行关联和聚合，划分出聚合的范畴和聚合根；

为聚合根设计仓储，并思考实体或值对象的创建方式；

在工程中实践领域模型，并在实践中检验模型的合理性，倒推模型中不足的地方并重构