你好，我是悟空。
上一篇介绍了 5 大软件架构风格，接下了我们看下游乐场电商平台项目中选择了哪几种架构风格。
该游乐场电商平台是一个比较复杂的系统，要求高并发、高可用，高性能。经过全面考量，需采用多种架构风格来完成该项目的架构设计。该项目采用了基于 SpringCloud 的微服务架构，用户端采用 C/S 架构，管理端采用 B/S 架构。在架构风格选择上，我们最终选择了层次架构风格、事件系统体系结构风格，数据库系统风格，面向对象风格。下面讲述我选择这几种架构风格的原因。 （1）分层架构风格：由于该项目既有C/S 架构，又有 B/S 架构，所以我们需要一个统一的服务端（Server），我们将服务端作为应用层，专门用于处理客户端和管理端的业务数据。应用层采用微服务架构，将应用拆分成多个应用，并以多个微服务和的方式进行部署，并配合注册中心Nacos来实现服务的高可用。如有一个微服务实例宕机，可以自动将流量切到其他实例。在应用层的上层还有一个网关层，专门用于处理认证、鉴权、流量治理等通用功能。网关层采用 SpringCloud Gateway 组件，流量治理采用 Sentinel 组件。 在应用层的下层是存储层，专门用来存储业务数据、缓存数据、消息队列数据。通过分层架构来解决架构的复杂性，提升了系统的性能、且能满足系统的高可用。 （2）事件系统体系架构风格：由于该项目是一个比较大的电商平台，所以涉及了订单、支付、物流发货业务，为了让电商平台更高效地完成电商业务，我们对整个交易流程的步骤进行了解耦，将每个步骤的结果推送到消息队列，并广播到订阅了相关 Topic 的下游系统，实现了高并发。由于该项目会发布一些秒杀活动，在固定时间点会涌入大量进行秒杀充值，对系统的性能和数据一致性要求极高，所以消息队列能有效解决上述问题。 （3）数据库系统风格：由于该项目要求高可用，我们采取了 MySQL 主从架构模式，当主节点宕机后，可以快速切换到从节点。MySQL 数据库主要用来存储业务数据，如用户的注册数据、交易数据、发货数据，存储五百万级的数据是没有性能问题的，另外我们采用了分库分表来对数据库进行扩容，实现了高可用。另外我们将热点数据放到 Redis 数据库中，能够更高效地查询数据，如用户的卡币数据。并且我们对 Redis采用了三节点部署，以及 Redis哨兵模式，能够实现宕机后自动切换，实现了 Redis高可用。该项目通过 RocketMQ消息队列存储消息数据，如订单消息、支付消息等。消息队列可以用来削峰填谷、异步解耦，实现高并发。 （4）面向对象风格：由于业务逻辑比较复杂，为了更好地实现用户和订单等业务逻辑，我们将用户、订单、充值卡、优惠券等都作为对象来处理。比如将充值卡的查询函数、充值函数、扣减函数封装在充值卡的对象中。并且充值卡对象具有自身的数据，比如充值卡的币数、充值记录，从而能够更合理的管理数据。通过面向对象的特性如封装、多态、继承，完美解决了系统的复杂性。
