摘要：
2020年3月，本人就职的某互联网公司承担了“XXAPP电子商务系统”的开发，该项目是集团为用户提供电子商务业务，拉新促活，提高交易效率的重点项目，主要实现消费者的网上购物和在线电子支付以及各种商务活动、交易活动。本人作为商城部门的核心成员有幸加入其中，担任架构师一职，主要负责该系统的需求分析和架构设计。该系统用户面向广大移动端和PC端互联网用户，主要用于提供用户网上订购、在线支付、广告宣传等服务，具有营销活动商品维护订单报表等服务能力。本文以该项目为例，最终确定本系统采用基于架构的软件设计方法，经过体系结构需求，体系结构设计，体系结构文档化，体系结构复审，体系结构演化等过程，为开发团队从结构上解决了业务难题，系统上线后得到了广大用户和集团对于系统的认可。
正文：
2020年3月，我参与了公司电子商务系统”的开发，担任系统架构师职务，进行系统的架构工作。该系统的外部实体主要是分为4类组织，用户，商户，系统管理人员，金融支付机构。电商系统有几个特点，模型多且复杂度高，数据流链路长，业务变化快，应对突发流量性能要求高等特点。包括商品库存、订单支付、营销活动、售后配送、用户权益、商户管理等几大业务模型。随着业务不断迭代之后，每个模型的边界和管理会越来越复杂和逻辑冗余。
考虑到系统的复杂性，项目整体采用软件体系结构设计，指的是从宏观层次对需要开发的目标系统进行描述。用不同的视图从不同的视角对目标系统进行分析与设计的过程。具体的过程可以分为，体系结构需求，体系结构设计，体系结构文档化，体系结构复审，体系结构实现，体系结构的演化等重要过程。
1、体系结构需求
在体系结构需求阶段，本项目先对目标系统的质量目标进行分解并结合用户提出的需求，分别整理出，功能性需求和非功能性需求。架构必须同时满足功能性需求及非功能性需求。通过分析得到以下几个架构核心关注点：1.数据的存储模型，由于每个商品可以分为普通商品和活动商品等不同类型，活动又分为预热期和活动期，以及周年大促、会员日、节日活动等活动类型，商户有自营商户和入驻商户，分别对应不同的后台信息管理类型等，订单分为实物、电子票券、酒店门票、充值等等，2.由于面向广大互联网用户每次商品、订单等查询时间必须小于2秒，7*24小服务，故障恢复时间不能大于1小时。3.本系统是一个交易类系统必须有动态参数设置及监控界面。
2、标识构件
通过分析系统的核心需求，架构组决定采用构件化开发进行整体的架构设计。设计基于模型属性和模型能力的抽象开发方法，设计使用event事件作为一个原子，组装和重发事件驱动，设计无锁的队列存储优化操作相同资源的性能。使用消费事件的方式提升开发效率，对物理模型和业务逻辑进行解耦。
3，标识构件之间的关系
根据总体架构设计形成了高层的构件，包括对象及对象状态构件、外部实体行为构件、消息事件构件、服务框架管理构件。业务模型继承和实现这些构件，如此商品，库存，支付，营销，权益，配送等业务模型都统一的具备了状态，行为，事件的能力构件，骨架完成后再填充各自的业务逻辑。
外部实体行为构件：原子的业务逻辑完成后，通过策略选择，迭代模式来配置和组装原子逻辑成为完整的业务流程功能。例如可以通过业务的策略来选择支付方式，也可以配置多条迭代校验规则完成业务上对商品的校验，这些策略和迭代规则都是配置化可以随意拆分组装。
消息事件构件：事件体系也是交易系统内部抽象的模型，它定义唯一的事件名称和唯一一的事件 ID,它支持同步或异步执行，支持不同线程上下文信息传递，支持写数据库设定，支持重试次数设定，支持自动的重试触发，支持无锁队列ringbuffer存放事件排队，支持多个事件组合成事件组，支持监控报警。以上是这个事件体系的特点。
服务框架管理构件：在下单支付等动作完成后，系统根据状态机映射触发对应的行为，行为中包括了系统服务调用和事件触发。在触发前把事件id，上下文信息放入redis缓存或数据库，事件自动存入无锁队列，系统的事件handle自动从队列中拉取对象和逻辑处理。在处理发生异常时，事件根据配置自动存入数据库等待重试或者丢弃。对于处理失败有通用的重试机制和监控报警规则，让开发快速发现线上问题。
4，技术选择
由于主从架构已经在大数据领域成功应用，同时也有成熟的开源组件。通过与客户讨论决定采用ZooKeeper为核心注册及主从架构管理组件实现负载。数据存储采用两级存储，MySQL作为核心数据存储，Redis数据库作为数据缓存，减少核心数据库的读压力。RabbitMQ作为消息核心组件。系统间通信采用基于HTTP协议的Restful接口形式。
5，架构文档化
根据设计意图，架构组采用4+1视图模型，对核心业务场景逻辑功能，开发架构，设计架构，部署架构，存储架构进行了描述并形成架构说明文档及需求质量设计说明书初版。
6，架构复审与细化
架构组与客户专家组对架构说明书，质量设计说明书进行了复审，并提出架构应考虑到数据的安全性，建议对数据库中的关键数据的加密，传输过程中的敏感数据采用加密和超时控制。架构组认为，数据库中的核心数据可以采用两种加密分别对不同数据加密。用户密码敏感信息采用MD5数字摘要算法进行加密，对于重要的金额数据采用对称加密。首次复审会议后架构组进行了架构的细化，确定了通信协义种类，主要接口，核心业务设计模式。并且对主要核心类进行的属性和方法的识别。再次经过与客户专家组讨论与评估，最终确定了XXAPP电商系统的架构。
此架构在后期的实现过程中经历一些调整，如下单改成多线程模式，消息通知失败的重试机制等部分，但总体结构稳定。系统上线后经客户专家组的验收反馈，本系统架构解决了需求中的核心关注点，并取得了很好的效果，关键是可以对系统运算能力进行水平扩展，能满足未来一定时期的业务需要。
结论：
经历XXAPP电商系统架构完整过程使我认识到架构不只是技术，而是要用技术解决客户的业务中的核心关注点，遵循一定架构过程和原则才能设计一个好的系统架构。也让我从中学到构件识别技术，比如构件的独立性，无可见状态，接口规约的版本一致性；构件关系组及架构评审相关知识。
