摘要：本人于2021年初参与了本公司某智慧导购营销系统的开发，并且作为架构组成员参与了项目整体的架构设计与评审，以及方案设计与评审。项目基线版本于去年十月份上线，至今已经平稳运行了一年，并且功能还在不断完善的进行持续迭代。由于用户数据量庞大，并且涉及到资产损失，客户对我们的软件系统质量属性要求比较高，为此我们对于产品架构的设计以及软件测试质量也相当重视，在架构设计和软件测试方面我们也做了大量的工作，最终系统上线之后，没有出现过大的纰漏，基本满足了性能要求，可靠性以及可修改性。本论文将详细阐述为满足业务需求跟项目目标以及软件质量属性的前提下我们对于软件架构风格的选择和应用，以及软件架构风格的特性进行论述。

        随着互联网的发展和社交流量的发展，零售行业也进行了营销模式的改变，依托互联网和社交平台来打造自己的私域流量营销平台成为了各个品牌行业的主流。我们的社交型客户关系营销系统为此提供解决方案。我们的产品主要依托微信生态，通过企业微信和微信两大公域来打造私域流量平台。对企业客户和客户群进行管理，客户聊天和客户群聊对客户进行引流，提供客户画像对客户进行精准营销，提供客户会话存档，敏感词校验，识别营销风险，支持客户标签，区分客户类型。作为流量的入口，客户对我们的系统质量属性有很高的要求，为满足良好的软件质量属性我们对软件系统架构设计尤为重视，为满足特定的应用场景以及良好的软件质量属性我们采用了分层的软件架构风格，基于Soa理念的微服务架构风格，以及独立构件-事件驱动（隐式调用风格），以及基于h5和小程序应用的RIA富互联网架构风格。

      首先，我们的产品是依托于企业微信，企业微信对我们提供了集成h5和小程序入口。导购端主要通过企微来跟客户进行社交沟通，为了丰富企业微信的功能，我们的产品承担了这一部分定个性功能，通过h5或者小程序链接这两富互联网让用户无感知的享受到我们产品提供的应用功能，客户无需再去专门下载别的app，无感知的富互联网架构风格使用户操作性得到了良好的体验，也对我们的产品功能达到了丰富，提升了客户满意度。

        其次，我们的产品依赖于企微的事件驱动需要做到数据的实时更新和处理。所以我们采用了独立构件-事件驱动的架构风格。Kafka是一个优秀的消息中间件，它通过事件通知来隐式通知来驱动我们产品服务的数据和业务逻辑的变更。它具有良好的消息支持模式，支持广播跟订阅，并且可以保持消息的不丢失，增加了系统可靠性。在客户通知等回调事件中驱动我们业务下游的数据统计以及客户关系等业务逻辑的变更，延期低，并发高，并且可靠性高。

        以上是基于第三方应用以及特殊业务场景的局限性我们可以选择的最优的架构风格。对于客户对系统可用性的质量属性要求，我们决定使用基于SOA理念的微服务架构风格。我们的产品通过领域划分成了多个服务，各个服务之前可独立部署运营，粗粒度，低耦合，也可针对流量较大的模块进行动态扩容（比如双十一等活动）流量会突增。我们每个模块部署也是集群部署，通过负载均衡技术，达到了模块的高可用。即使有服务节点挂了也不影响其它服务的运行，软件可用性得到了保障。由于工期比较紧张，我们采用不同的迭代组对拆分后耦合度低的领域模块进行并行开发，前后端分离，提供标准的rest api服务接口。服务与服务之前也是基于rest api进行通信。服务的注册与发现基于阿里巴巴的nacos注册中心，可支持集群和充当配置中心。微服务架构风格解决了服务解耦和高可用，也缩短了软件开发的成本，但是随之增大了运维成本和部署成本，但是基于项目需要的考量，以及客户的要求，利大于弊所以我们选择了微服务的架构风格，也基本达到了设计目的。

        在我们单个服务的设计过程中，我们是基于java springboot 和springcloud alibaba开发的。我们采用了调用-返回的软件分层的架构风格。在硬代码层面 spring mvc 提供了mvc分层模式。view是视图层，controller是控制层，modle是实体层和业务逻辑层。实际上我们对后端服务进行了以下分层，首先最外层是api层，分为内部api和外部api 内部api提供服务间调用的接口，外部api 提供客户端调用接口。其次往下是聚合层，负责聚合多领域的业务逻辑处理。再往下就是领域层，包括领域实体以及领域模型，这是对领域用例抽象的提取与实现，此层是比较重也是最重要的一层，我们把事务也放在了这一层，如果在应用层描述用例中使用了事务，从写法很容易把多个聚合下的事务形成一个大事务，如果是放在领域层，只会有当前业务域内的事务，相当于本机事务，事务的一致性仅在业务域范围内部更加可用，无需引入分布式事务。部分有关联业务域可用遵循 BASE 理论的最终一致性。对于上面微服务架构的最大的缺陷，事务的一致性有了一定的处理机制。再往下一层是数据操作层，对于数据库的操作放在了这一层，包含实体与数据库的映射，处理数据库操作，以及和领域层交互。领域层的实体跟数据库实体会在这一层有一层的转化。

      其次还有基础设施层，这一层包含了产品的基础组件，像数据库mysql以及内存数据库mysql 搜索引擎es以及消息队列还有定时任务等等。

      在项目中，我们对基础资源的生命周期进行了抽象，包含初始化、安装、启动、停止、启动时是否异步、在需要该基础资源的时候将其注册到启动管理器中，然后循环遍历启动管理器，调用启动器的初始化、安装、启动方法，只要对应资源实现了相关对应抽象，这样基础组件就像插件一样。另外，为了系统软件的可修改性以及可变形，后续自研或者替换产品，我们在基础组件之上简简单单的封装了一层，方便以后替换以及复用。

        总结，以上就是我们在产品研发过程中为达到客户需求已经软件质量属性所应用到的架构风格，各种架构风格提供了不同类型的解决方案以解决不同的场景问题，上线将近一年了，期间经历过618活动的冲击，系统还算平稳运行，客户也比较满意，但是架构很难十全十美，也很难一次到位，因为需求在不断的变化，系统的体量也在逐渐增大，所以项目在不停的变化中，架构也要随之调整，既有调整也要有抽象化的可复用性，只有能经历不断演化且软件质量不降低或者还能提升的架构才是健壮的架构。我们需要努力提高能力，经过不断的学习，提升软件设计水准，为行业和社会贡献自己的一份力量。