系统架构师论文--论系统架构风格应用

系统架构师论文–论系统架构风格应用

tip:论文结构解析请看https://blog.csdn.net/lqb3732842/article/details/134081532

摘要
作为国内美容行业领先的咨询服务公司,2020年5月,我司自研开发一套提供SAAS服务的美容行业客户管理系统,致力于为行业提供一套标准的客户管理流程。系统主要包含组织架构模块、客户引流模块、客户管理模块、商品订单模块、线下会议模块、在线合同模块及系统服务模块等7个主要功能模块。作为系统架构师我负责整个项目的系统架构工作。本文以此项目为例，主要论述系统架构风格的应用,系统采用了微服务架构风格,通过微服务架构，将系统分解为多个服务，前端Web服务解决前台并发问题，后端中台务实现基础服务框架，业务服务实现具体业务功能，解决协同问题。各服务采用不同技术开发，独立部署，系统的性能、可靠性与扩展性得到了大的提升。最终系统顺利上线，获得用户一致好评

我司是美容行业领先的咨询服务公司,一直致力于为行业提供一套标准的客户管理系统.SAAS客户管理系统就是我司根据行业几千家客户中通过十几年的服务经验总结沉淀下来的一套服务于美容行业的可落地的客户管理系统.系统整体是一套以SAAS服务为基础的2b2c的客户管理系统,主要角色有平台管理运营人员,商户员工,商户B端客户及商户C端客户.不同角色对应不同的应用入口,应用主要载体是app+小程序+公众号+pc管理后台.系统架构为微服务架构,主要模块有组织架构模块,引流模块,商品订单模块,客户管理模块,线下会议模块,在线合同模块及系统服务模块等.用户通过引流模块推荐文章或者视频给顾客，客户管理模块将通过顾客行为数据进行用户分析，完成用户画像。用户再根据顾客画像进行产品促销或者推广。对于B端客户可以通过线下会议模块组织线下会议，完成现场会销。最后通过在线合同模块完成合同的在线签署。系统服务为所有业务提供必要的功能支持,如：问卷调查、二维码生成、短信通知等。

常用的软件架构风格分为五类：数据流风格、调用/返回风格、独立构件风格、虚拟机风格、数据仓库风格。数据流风格包括批处理、管道-过滤器；
调用/返回风格包括主程序/子程序、面向对象、层次结构；独立构件风格包括进程通信、隐式调用；虚拟机风格包括解释器、规则系统；数据仓库风格包括数据库系统、黑板系统、超文本系统。此外，架构风格还有MVC、SOA、微服务等。其中，层次结构风格将构件按层次组织，每层为上层提供服务，使用下层服务，只能接触邻层；进程通信风格将构件作为独立过程，通过消息传递调用；微服务架构将单一应用划分为多个松耦合的小服务，相互协调配合，采用轻量级通信机制，各服务可选择不同技术，支持独立部署。本文以此项目微服务架构为例,详细介绍项目的整体架构及实现,主要从架构必要性,架构设计,架构实现三个方面详细展开论述.

一:微服务架构必要性
SCRM系统是基于SAAS服务的客户管理系统,需要直接面向多端客户,一般客户管理系统使用CB/S多层架构方案,后端通过MVC实现多层控制.但是考虑到SCRM系统整体业务模块繁多且用户数量会可能爆发式增长,对系统性能及可靠性要求极高,很多问题以往单体架构难以解决.
单体应用主要有性能,项目管理,项目更新,技术异构兼容等难以处理的的问题.性能上,单体项目聚合各个功能模块,当各个模块同时并发都同时到来时系统整体并发可能会超过负载,出现服务异常.仅通过单体负载均衡很难达到系统并发要求,只有通过业务拆分,分摊各模块流量才能更好保证系统的可用性.项目管理上,随着项目的变大人员的增加,整个项目管理将变得杂乱,低效,
尤其是公司团队可能在不同的城市,共同开发一个项目,交流管理成本会非常高.微服务把项目拆分为多个服务,每个服务独立开发,测试打包部署,由各自团队独立负责,服务之间通过文档调用,无需额外过多沟通,大大提高系统开发管理效率.项目更新上,单点项目迭代更新牵一发而动全身,可能只是某个功能模块的小修改,但是也要重新打包整个项目,无关的功能模块也会受到影响,拆分为多个服务后,单个服务更新迭代不影响整个系统其他模块的使用,可以大大提高系统可用性.

二:微服务架构设计
SCRM系统整体为微服务架构,采用前后端分离方式,分为前端web集群,后端服务中台,后端业务聚群3个层级.前端集群通过nginx实现负载均衡,当用户访问前端web页面时首先通过nginx负载均衡到前端web服务集群,web服务集群返回web网页给前端,之后前端通过ajax方式获取数据.后端中台是微服务的核心,主要包括网关应用集群,注册配置中心,包含服务发现及管理,服务负载功能等核心功能.前端访问数据直接通过调用网关API接口,网关首先通过注册中心获取已注册可用的服务,注册中心按照负载均衡原则返回可用服务地址,之后网关根据服务地址调用各个需要的服务完成收集聚合返回给前端.后端业务服务集群则是各个独立的微服务应用集群,每个服务部署后都会通过接口注册到注册中心,服务之间也会从注册中心获取需要的可用服务.整体架构有四大集群,web页面集群,网关集群,注册中心集群,业务服务集群
通过平台中台协调完成系统各功能.

三:微服务架构实现
完成架构设计后主要任务是实现和组装系统构件。本着不重复造轮子及技术兼容的为主的观点,我们尽可能的使用开源可用的组件来完成架构组建.
网关是整个系统核心应用,考虑到性能和开发效率,我们使用了主流的java 组件zuul作为网关应用,包含了流量控制,服务熔断,降级等功能,整体通过负载均衡方式实现集群.注册配置中心作为服务的核心需要兼容各类主流技术平台,SRCM系统线下会议模块下的人脸识别签到中需要使用到人脸识别,检测等服务是通过python语言实现提供服务.最终我们选择阿里巴巴开源的nacos作为注册配置中心.nacos原生分布式架构,可以根据性能需求调整节点数量,包含服务注册,服务发现,服务负载均衡及统一配置等核心能力.服务容器跟容器管理则选用了主流的docker 跟k8s搭配,对于具体的业务服务实现根据负责团队的技术需求各自实现,只需最终打包运行后能跟注册中心对接就可以.服务通信协议则选择了grpc,tcp层协议,完成服务之间的数据交互.
通过各组件的集成,调试,最终实现整个微服务架构设计.

总结
经过微服务的架构风格设计,实现,项目于2021年6月完成上线,经过2年多的运营,现在系统拥有商户1500+,C端客户总数800w以上,系统多次支持了百万级用户秒杀,抢购活动,整体得到公司与用户的一致好评.在系统架构实现中也经历了很多问题如分布式事务一致性保证,服务接口文档不统一,不完善等问题.通过引入分布式事务锁解决了分布式事务问题,通过搭建系统文档中心及文档插件工具使用解决了服务接口文档效率低下不完善的问题.此次系统架构,也让我看到自己的很多不足,在未来会不断地更新知识,完善系统在各方面的设计.