论企业应用系统的分层架构风格
摘要
本文以2019年3月,我主持的江苏省气象局智能化预报服务平台为实例,探讨了企业应用系统的分层架构风格,认为分层架构符合当前项目架构设计,首先简单阐述每个层次的主要功能,然后结合实际情况说明每个层次设计时,需要注意的问题及相应的解决方案。在此项目中,我担任了系统架构设计师,参与了江苏省气象局智能化预报平台架构设计,实践证明,在项目开发中,使用分层架构,加速了项目进度、降低了项目风险,节省了项目开发成本,使系统具有良好的,扩展性、可移值性、开放性。系统上线已来运行稳定,在应用对今年淮河防汛防洪工作表现突出,得到了相关局领导的高度认可。
正文
随着互联网技术的发展,互联网网站、电子邮件、短信等数字化服务逐渐替代了传统的服务形式,信息传输效率、信息量和服务及时性等方面有一定提高。然而各种方式在接收时间、内容和手段上都具有一定的局限性,各预报系统之间缺乏交互性,预报预警系统之间集约化程度不高,信息流转效率难以提升。针对预报业务流程缺乏整合和业务流程自动化智能化水平低的问题,对业务流程进行全面梳理,建立突发流程的常态化运行机制,开发业务流程智能化系统,实现业务流程全面信息化,完善业务流程跨部门衔接,提高全流程精细化业务管控能力,通过流程自动化和智能化水平的提高,节省人力,提高业务流程的运转效率。
高标准建设智能预报服务平台,进一步深入挖掘气象数据分析和应用,能够为客观、科学的气象分析和预测起到积极的作用。一个好的工作平台,能够提高工作效率,能够尽可能的减少重复性的操作,也能够减少中间环节出现错误。智能预报业务平台具有实况信息监测、重要天气警示、工作任务提醒、报文编辑发送、预报制作发布等功能,集成化、智能化程度高,功能完备,具有较强的可操作性和实用性,使日常预报业务服务工作的系统化、自动化、规范化上了一个新台阶。
本系统使用多语言混合开发,基于 SpringBoot、mybatis 框架作为后台底层基础,基于 javaScript、Object-c、android, MVC框架作为前端应用,整个系统主要采用分层模式、每个功能都是基于组件方式进行开发、页面展现采用模板等技术开发,前端后端分离,采用 HTTP进行通讯,通讯的内容基于 JSON 进行序列化和反序列化,不同部门之间的系统数据通过 API进行数据交互。通过 redis 缓存提高系统性能增强用户体验。
层次结构风格是调用返回风格的具体风格。层次结构风格组织成一个层次结构,每一层为上层服务,并作为下层客户。本项目中我结合实现情况把项目分为两层。
前端:主要负责接收用户的请求,对用户的输入、输出进行检查与控制。处理客户端的一些动作,包控制页面跳转等,并向用户呈现最终的结果信息。表现层主要采用 MVC结构来实现,控制器负责接收用户的请求,并决定应用调用哪个模型来处理。然后模型根据用户请求调用后,进行相应的业务逻辑处理,并返回数据。最后控制器调用相应用的视图来格式化模型返回的数据,并通过视图呈现给用户。
后端:后端主要包括,控制器层、业务逻辑层、业务逻辑层实体(VO)、数据库访问层。控制器层,主要用于,接收、返回、跨域实现、安全控制;业务逻辑层分为业务处理类和实体类两部分,业务处理类主要功能是对业务功能的抽象,把具体的业务抽象成控制器可调用,可加工的的资源;业务逻辑层实体提供了对业务数据的状态编辑访问,业务逻辑层实体可以使用具有复杂架构的数据来构建,这种数据通常来自数据库中的多个相关表,一些高频数据通过业务逻辑处理类保存到缓存数据库中。业务逻辑层实体是可以序列化的,以保持它们的当前的状态。数据库访问层,主要是负责数据的持久化存储,即将业务数据存储在文件、数据库等持久存储介质中,主要功能是为业务逻辑提供透明的数据访问、持久化、加载等能力。
下面我来说明实现设计中遇到的一些问题以及我的解决方案。
前端:通过对需求的分析,本项目需要多终端显示和应用,手机 app、电脑浏览器、智能机器人,导致前端需要多语言混合开发,所以在设计项目整体架构时,前端各终端都采用统一的 MVC结构,
1:后端代码可重用,只要定义好 api 就可以并行开发
2:前端开发不用重度依赖后端,前端引用 MVC 降低
终端表现层与终端模型层的耦合度，各终端的模型层对数据进行统一处理,转换成统一的JSON结构,在通过主流的 HTTP协议作为数据传递的载体,与后端进行交互。
后端:为了缩短开发周期,降低开发难度,解决跨域、权限控制、性能(天气实况数据要快速及时)、SQL注入、web容器国产化等题,通过研究与分析,我们引用了主流的 Springboot 用于实现控制器层、业务逻辑层、业务逻辑层实体; MyBatis结合 Springboot实现数据库访问层; web容器选用了国产 Apusic,因为关系数据库在处理海量的天气数据时查询慢,无法满足现在性能要求,我们选用 redis作为缓存数据库。因篇幅的影响下面我只重点拿几个框架与数据库来解说。
Springboot的优点:1拆箱既用,项目搭建简单(约定优于配置)节约成本缩短周期,2便于实现 RESTAPI,3非常简洁的安全策略,4集成支持关系数据库和非关系数据库,5支持多种类别的 web容器,6支持热启动,7跨域实现只需简单配制注解。由于以上优点 Springboot解决了项目中的,跨域、防问权控制、降低了开发复杂性、节约了成本、缩短项目周期,等问题。MyBatis 的优点: MyBatis是一款优秀的持久层框架,它支持自定义 SQL、存储过程以及高级映射避免了几乎所有的JDBC 代码和手动设置参数以及获取结果集。
MyBatis 可以使用简单的XML 或注解来配置和映射原生信息,将接口和 Java 的数据库访问层中的实体类映射成数据库中的记录。1易于上手和掌握,提供了数据库查询的自动对象绑定功能,而且延续了很好的 SQL 使用经验。2sql 写在xml里,便于统一管理和优化,解除 sql 与程序代码的耦合。3提供映射标签,支持对象与数据库的 orm 字段关系映射。4可以防止 SQL注入提搞了安全性。由于以上优点 Mybatis 解决了项目中的,SQL 注入等问题。
Apusic 的优点: Apusic web容器完全自主可控,工业规范与标准,具备了数据持久性、事务完整性、消息传输的可靠性、集群功能的高可用性、以及跨平台的支持等特点,为全软件国产化道路走出了一小步。
redis 的优点: 1redis 查询速度快,因为数据存放在内存中,2支持丰富数据类型,支持 string、 list、 set等,3支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行,4丰富的特性、可用于缓存、消息,按 key设置过期时间,过期后将会自动删除。由于以上优点 redis 解决了项目中的,mysql应对海量数据的查询慢的问题,还解决了因为气象实况数据,实时性很强,以往都要写定时间器定期去mysql中进行数据删除,增加了开发工作,也加大了 mysql数据库的性能开销,现在删除气象实况数据的工作进行转移,以前删除气象实况数据的工作与时机是由我们自己把控(定时器),而现在这种工作我们转移给了redis,只需在缓存时设置 key的过期时间,数据就是自己删除。
最后通过项目组成员的共同奋斗,我们按期完成了任务。采用这样的体系结构,完全满足要求,并且安全可靠、容易维护、方便扩展、结构模块化、易操作。经过用户一段时间的使用,系统稳定可靠,在此其期我们对前端表现层作了相应用的调整,在修改测试后可以热度发布,不会影响应用系统的正常运行,这也充分的体现了分层设计风格的低耦合性与分而治之的思想。此次系统的顺利实施,为我以后的工作提供了很好的帮助。同时,软件技术的日新月异也促使我要不断更新自己的知识结构,为应对不同体系结构的软件分析与设计做好准备。
论企软件架构风格
摘要
我所在单位是国内某商业银行,2017年1月我行决定开发全新一代绩效考核平台系统,我担任本次系统开发的架构师,主要负责整个系统的架构设计工作。该系统既满足内控管理的绩效考核,又满足银行粉丝客户参与营销的综合性绩效平台,是银行应对互联网金融变革和笃行普惠金融的重要系统。本文结以绩效考核平台系统在建设中与银行其他系统集成为例,先介绍几种常用软件架构风格及特点,然后结合本次项目采用数据流风格、调用返回风格、独立构件风格、虚拟机风格以及仓库风格,论述了该项目在软件架构选择过程中,为何选择了五种风格的组合,最后总结一下使用多种架构组合时候遇到的问题。通过适当的架构风格选择和组合使用,我们的系统开发取的了成功,目前系统已经稳定运行 1年多,得到了领导、员工、客户的一致好评。
正文
我所在的单位是长三角地区某城市商业银行,机构覆盖全国多个省、直辖市。目前银行业正面临互联网金融浪潮的冲击,银行需要积极转型、自我变革,不仅要服务好优质客户还要抓住普通大众客户, 发展新零售拓展小微企业客户业务成为当下银行的战略要点,绩效考核将充当银行战略转型的有效指挥棒角色。正是在这一背景下我行提出建设全新一代绩效考核平台,既对传统的绩效考核做出调整,又结合互联网化的“粉丝及员工”理念,搭建多维度、多渠道、多群体的绩效考核平台。
(一) 数据流风格:包括批处理序列架构风格和管道/过滤器架构风格。
(1)批处理序列架构风格。组件为一系列固定顺序的计算单元,组件间只通过数据传递交互。每个处理步骤是一个独立的程序,每一步必须在前一步结束后才能开始,数据必须是完整的,以整体的方式传递。
(2)管道/过滤器架构风格。每一个构件都有一组输入和输出,构件读取输入的数据流,经过内部处理,然后产生输出数据流。缺点是:不适合及时的交互式设计;由于缺乏统一的通讯标准, 数据的传输效率可能比较不高。
(二) 调用/返回风格:包括层次结构架构风格,主程序/子程序架构风格和面向对象架构风格。
(1)层次结构构架风格。层次系统组织成一个层次结构。构件在一些层实现了虚拟机。连接件通过决定层间如何交互的协议来定义,拓扑约束包括对相邻构件交互的约束。这个风格的特点是每层为上一层提供服务,使用下一层的服务,只能见到与自己邻接的层。大的问题分解为若干个渐进的小问题,逐步解决,隐藏了很多复杂度。修改一层,最多影响两层,而通常只能影响上层。上层必须知道下层的身份,不能调整层次之间的顺序。
(2)主程序/子程序架构风格。单线程控制,把问题划分为若干处理
步骤,构件即为主程序和子程序。子程序通常可合成为模块。过程调用作为交互机制,即充当连接件。调用关系具有层次性,其语义逻辑表现为子程序的正确性,取决于它调用的子程序的正确性。
(3)数据抽象和面向对象架构风格。是将数据的表示方法和它们对应的操作方法封装在一个对象中。对象和对象之间通过函数和过程调用来交互。这种风格的构件就是对象,连接件就是函数和过程的调用。这种结构风格中包含有封装、交互、多态、集成和重用等特征。
(三) 独立构件风格:包括进程通信架构风格和事件驱动架构风格。
(1)进程通信架构风格。构件是独立的过程,连接件是消息传递。这种风格的特点是构件通常是命名过程,消息传递的方式可以是点到点、异步和同步方式及远过程调用等。
(2)事件驱动架构风格。构件不直接调用一个过程,而是触发或广播一个或多个事件。系统中其他构件中的过程在一个或多个事件中注册,当一个事件被触发,系统自动调用在这个事件中注册的所有过程。主要优点是为软件重用提供了强大的支持,为构件的维护和演化带来了方便;其缺点是构件放弃了对系统计算的控制。
(四) 虚拟机风格:包括解释器架构风格和基于规则的系统架构风格。
(1)解释器架构风格。一个解释器通常包括完成解释工作的解释引擎,一个包含将被解释的代码的存储区,一个记录解释引擎当前工作状态的数据结构,以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机,可以仿真硬件的执行过程和一些关键应用;其缺点是执行效率较低。
(2)基于规则的系统。基于规则的系统包括规则集、规则解释器、规则/数据选择器及工作内存。
(五) 仓库风格:包括数据库架构风格和黑板架构风格。
(1)数据库架构风格。数据库架构风格是最常见的形式。构件主要有两大类,一个是中央共享数据源,保存当前系统的数据状态;另一个是多个独立处理元素,处理元素对数据元素进行操作。
(2)黑板架构风格。黑板架构包括知识源、黑板和控制 3个部分。知识源包括若干独立计算的不同单元,提供解决问题的知识,知识源响应黑板上的变化,也只修改黑板。黑板是一个全局数据库,包含解域的全部状态,是知识源互相作用的唯一媒介。黑板通常应用在对于解决问题没有确定性算法的系统中,例如信号处理、问题规划及编译器优化等软件系统的设计中。
首先本次项目觉得采用J2EE 技术开发B/S架构的系统,绩效考核平台还需要数据仓库提供相关业务指标数据,并采用 SOA架构与我行多个业务系统进行集成。在架构风格选择上,最终我们选择了管道过滤器架构、分层架构、进程通讯架构、基于规则的系统架构和数据库系统几种架构风格,进行混合使用。下面讲述我选择这几种架构风格的原因。
(1)管道/过滤器架构风格和进程通讯架构风格选择原因。由于绩效考核涉及到的考核指标数据和客户数据都需要数据仓库提供,通过 IBM Data Stage ETL中间件每天日终从仓库批量抽取数据后,通过转换任务进行逻辑处理,每个转换都有一组输入流和输出流,许多个转换任务一起协助构成一个完整日终处理。绩效考核平台需要与HR、流程中心、门户等系统进行密切交互,涉及到异构系统之间进行通信, 业务模块通过远程调用其他服务和点到点异步消息通讯。
(2)分层架构风格和数据库系统风格选择原因。本次采用的 J2EE 本身就具有N层架构的特点,我们采用表示层、业务逻辑层、数据持久层分离的架构来开发B/S系统,每层只为上一层提供服务,是典型的分层架构。数据持久层保存的数据和ETL 抽取的数据都保存到IBM DB2 10.5数据库中,业务逻辑涉及到数据的都与中央数据库交互,使用 JDBC 接口对数据库进行增、删、改、查等操作。
(3)基于规则的系统架构风格选择原因。由于绩效考核涉及到的考核规则变化非常快,每次变化后需要很短的时间进行相应,经过分析, 绩效计算则通常需要将机构、客户属性、产品、业务指标、计价系数等通过规则不断组合、变换后再进行解释计算,为了满足复杂绩效计算这一特性使用传统的硬编码显然不可行,我们采用基于 java 开源Drools 规则引擎框架,通过规则引擎来实现复杂的计算绩效计算。当然在多种架构风格组合开发系统时候,我们也遇到了一些问题,单我们都想办法进行了解决。使用Drools 规则引擎时候,由于计算的数据量非常大,导致计算出全行绩效都到第二天中午,效率低下,经过测试分析采用 Drools 集群加分组并行运算,将绩效计算提高到90分钟内算完。还用使用Drools规则引擎表达式是通过写配置文件实现,维护规则表达式业务人员无法完成,制约了使用,针对这一问题,我们采用购买了对 Drools 规则表达式能可图形化操作的商业组件。
通过本次项目中系统实践,体会到,现代信息系统结构复杂,要集成的系统也非常的多,多种架构风格融合是一个必然选择,且新型的架构风格不断涌现,合理选择对开发、复用非常重要。经过 7 个月的开发,绩效考核平台已经顺利上线并稳定运行 1年多,充分发挥了绩效激励、赛马式营销、政策指挥棒的作用,目前已在全行推广使用,得到了领导、员工、客户的一致好评。
论软件系统架构风格v5.0
摘要
统一支付平台建设推广应用项目是我市卫生健康委员会2019年发起的一项医疗卫生行业便民惠民信息化项目,目的是实现辖区内患者在辖区各公立医疗机构就诊时,可以使用微信和支付宝在线支付挂号费、门诊费和住院预交金功能,我作为系统架构师参与此项目。本文围绕软件系统架构风格这个主题,首先介绍管道与过滤器风格、数据抽象和面向对象系统架构风格,基于事件的系统架构风格,数据库共享风格、轻量级J2EE多层架构风格,REST风格等多种常用架构风格,然后较为详细的说明,在统一支付平台开发建设过程中,使用轻量级 J2EE 多层架构(Vue+SpringBoot+myBatis 框架),REST架构风格,数据库共享风格以及集群部署架构风格等,项目经过一年时间的设计开发集成,顺利通过验收并稳定运行,辖区各医疗卫生机构对此平台非常满意,给予高度评价。
征文
随着互联网技术在医疗卫生行业的广泛应用,互联网+医疗便民惠民服务受到各级政府的高度重视,比如:在线预约挂号、移动支付、居民电子健康档案在线查询、远程问诊、远程会诊等等。2019年,我市卫生健康委员会启动了统一支付平台建设推广应用项目,目的是实现辖区内患者在辖区各公立医疗机构就诊时,可以使用微信和支付宝在线支付挂号费、门诊费和住院预交金功能。我作为系统架构师参与此项目。
软件系统架构风格是描述特定应用领域中软件系统组织方式的惯用模式,反映了领域中众多系统共有的结构和语义特征,用于指导将各个模块和子系统有效地组织成完整的系统,下面我将围绕软件系统架构风格这个主题展开讨论,首先介绍常用的软件系统架构风格,然后详细说明统一支付平台项目建设推广应用项目中用到的一些架构风格和实施效果。
常用的软件系统架构风格有管道与过滤器风格、数据抽象和面向对象系统架构风格,基于事件的系统架构风格,数据库共享风格、轻量级J2EE多层架构风格,REST风格等。
管道与过滤器风格属于数据流风格,这种风格中,构件叫做过滤器,有一组输入和输出,构件读取输入的数据流,经过内部处理后,产生输出的数据流。连接件叫做管道,它可以将一个过滤器的输出数据流传递到另一个过滤器的输入。
数据抽象和面向对象系统架构风格属于调用/返回风格,这种风格的构件是对象,它将数据的表示方法和相应操作封装在一起,在软件开发过程中作为一个整体单元来考虑。连接件是对象之间用于交互的方法调用。
基于事件的系统架构风格属于独立构件风格,其思想是构件不直接调用一个过程,而是触发或者广播一个或多个事件,其他构件包含的过程在一个或者多个事件中注册,系统自动调用在这个事件中注册的所有过程。
数据库共享风格属于仓库系统风格,这种风格包含两种不同的构件,中央数据结构说明系统当前的状态,独立构件在中央存储上执行,输入流中某类时间触发进程执行的选择。
轻量级J2EE架构风格属于分布式层次架构风格,这种架构风格将系统组织为一个层次结构,每一层为上层提供服务,并作为下层的客户使用下层提供的服务,大多数情况下,内部的层只对相邻两层可见,层与层之间通过规定的协议来交互。轻量级J2EE 多层架构风格一般分为视图层、控制层、服务层、数据访问层、数据持久层和数据库服务,视图层用于检查用户的输入和显示应用输出;控制层用于处理用户动作、调用服务层服务和选择响应视图;服务层主要用于实现业务逻辑;数据访问层,用于处理对象的存储和访问;数据持久层用于将访问层对象存取操作转换为数据库 SQL语言,然后操作数据库,数据库用于保存数据。
表述性状态传递(REST)架构风格是一种 Web软件架构风格,通常基于 HTTP、URI和 XML 等广泛流行的协议和标准,在REST中,使用 URI来定位资源,使用 HTTP 动词(GET、POST、PUT 等)来描述对资源的增删改查操作、REST可以更高效的利用缓存来提高响应速度,同时 REST 的会话状态由客户端来维护,这样可以实现不同的服务处理不同的请求,提高服务的扩展性。
统一支付平台主要实现5个功能:1、患者通过扫描自助机屏幕显示的付款二维码来完成支付;2、缴费窗口工作人员使用扫码设备扫描患者手机上的缴费码来完成支付;3、患者通过辖区健康微信公众号在线缴费;4、患者通过辖区健康手机 APP 来在线缴费。5、财务人员使用 web 浏览器进行商户管理、用户管理、订单管理、对账管理和交易监管。非功能需求优先级为:可靠性、可用性和安全性为高优先级,性能和可修改性为中优先级,易用性为低优先级。
统一支付平台使用轻量级J2EE多层架构、实现前后端分离,前端运行在各医院财务人员的网页浏览器上;后端应用服务器和数据库部署在服务器集群上。平台需要与辖区健康 APP、辖区健康微信公众号以及各公立医院信息系统(医院 HIS 系统),医院自助机系统等实现集成。集成使用 REST 架构风格为基础的分布式事务架构。平台和HIS 系统、自助机通过互联网或者主备VPN 专线连接。轻量级J2EE 多层架构方案:视图层采用 Vue网页用户界面渐进式构建框架和 Element 页面组件库实现; Web 服务层(控制层)、服务层和数据访问对象层使用 SpringBoot框架实现,数据持久层选用 myBatis实体关系映射框架。
基于REST 架构风格的分布式事务架构方案:统一支付平台应用服务器与其他系统集成时,通过REST交互,内部使用 HTTPS和JSON, 以提高安全性和降低各医疗卫生机构的集成成本。平台提供账单回滚接口,当支付遇到问题时,医院信息系统或自助机系统会使用后台创建退费订单的方式来调用回滚接口,将用户的缴费状态重置为未缴费,否则,就需要收费窗口人员手工登录支付平台退费,既浪费时间,又容易引起患者投诉。与这个方案配套的设备有网闸、防火墙、入侵检查系统、SSL VPN 安全网关服务器等。
基于数据库共享的批量对账架构方案:为了进一步提高资金安全性,医院信息系统每日1点将前一天的支付数据上传到指定的mysql数据库,然后统一支付平台每日3点从这个 mysql数据库抓取数据,导入平台数据库后开始进行对账操作,为了降低网络不稳定的影响,医院信息系统使用消息队列实现上传重试机制,每日上传时,自动上传一周内未上传的数据,支付平台对账工具每日对账时,也会检测前一周内未对账的数据,并重新对账。批量对账既是财务日常监管的工具,也是平台可靠性提升的重要辅助工具,在系统运行初期,我们通过分析批量对账异常,发现许多系统问题。
服务器集群架构方案:平台应用服务器部署在多台虚拟机通过 Nginx 集群组建成的高可用负载均衡集群上,而数据库服务器部署在两台小型机组成的 Oracle RAC实时应用集群上,操作系统为 CentOS 7.4,数据存储使用多台SSD 和SAS混合磁盘存储阵列通过光纤和光纤交换机组成的存储区域网络。
主备VPN 专线架构方案:平台和医院信息系统通过电信卫生专网和移动卫生专网连接,电信卫生专网为主线路,移动卫生专网为备用线路,医院信息系统客户端实现专网监测和主备切换。
统一支付平台建设推广应用项目经过一年的设计开发和集成,顺利通过验收并稳定运行,辖区各医疗卫生单位对此系统非常满意,给予高度的评价。通过本次项目中实践,我体会到,医疗卫生行业信息系统的结构正变得越来越复杂,系统需要集成的组件也越来越多,多架构风格融合已经是一种必然选择,为不同组件选择合适的架构风格正变得越来越重要。
论微服务架构
摘要:
2017年10月,我被任命为系统架构师参与了 XXX 运营商AOP系统架构升级项目,负责架构设计工作,该系统是运营商面向互联网销售产品的系统,自从年中上线流量包订购业务以来,系统订单量飞速涨,月末订单量达10余万笔,客户希望通过营销活动进一步提升订单量,并承载更多业务,但我们评估当前架构无法支撑客户需求,因此提出本项目。
本文以此项目为例,论述了微服务架构的在项目中的实际应用;首先我梳理了微服务架构的思想、优点和挑战因素,然后分析了本项目的系统现状、影响可靠性的风险点,再大致交代了解决可靠性问题的举措,然后重点论述了采用微服务架构如何达成架构升级目标;最后制定了本次架构升级的技术方案,评审并实施后,经过1年多来的稳定运行,成功达成了设计目标,获得客户一致好评。
正文
微服务,是面向服务架构的一种,顾名思义,微服务架构下,服务的粒度很小,每个服务专注于一件事情,微服务架构提倡将系统拆分成一系列细粒度的服务,通过服务的编排组合实现业务需求,服务间通过轻量级通讯协议交互,从而支持微服务架构的系统达成松耦合、组件化、高扩展、高弹性、可修改行、可替代性俱佳的目标,最终提高系统的交付速度,提高交付质量。
微服务的好处很多,首先,它很适合成为新技术的试验场,每个服务都是独立的,可以根据服务自身需要采用合适的技术,如社交网络适合采用图数据库,而结构化数据适合采用关系数据库;其次,微服务系统对外提供了众多的服务,系统的可组合性好,业务变化时能轻易组合服务实现;再次,微服务的可替代性、弹性、可扩展性都很好,服务可以独立替换,每个服务可以内置自己的降级限流方案,也可以独立扩展性能,方便调整系统的整体处理能力。
微服务虽说有很多好处,但也有很多挑战,首先,几乎所有业务需求都需要通过服务的编排组合实现,服务间的通讯开销可能影响性能,同时数据的一致性、可靠性等都可能受影响;其次,运维成本高,相对单体应用,微服务数量众多,每个微服务都需要独立部署,运维监控、运行成本高昂;再次,自动化部署的要求,服务间依赖关系的管理,服务依赖的测试都是挑战,需要妥善解决。
微服务架构只是一种理念,具体的实现框架技术中,SpringCloud无疑是最为成熟的,Spring 生态强大的集成能力体现无疑,微服务各方面的需求都有对应的组件能满足,如服务网关 Zuul、注册中心 Eureka、容错降级Hystrix、客户端负载均衡 Ribbon、配置中心 Spring cloud config等,为微服务系统开发提供了全面的支持;除此之外,基于阿里巴巴开源的 Dubbo服务治理框架也是一种选择,相对来说它没有那么全面的组件支持,但国内应用此框架较多,经历过互联网企业巨大流量的历练,框架成熟度较高。
2017年10月,我被任命为系统架构师参与 XXX 运营商AOP系统的架构升级工作,负责架构升级方案制定,组织架构升级工作实施,本次架构升级的目标是提高系统的性能扩展能力和可靠性,为互联网营销活动提供支撑。该系统是XXX运营商面向互联网销售产品的系统,目前承载了宽带业务订购、存费送费活动、流量包订购等业务,其中流量包订购业务占据总体业务量的绝大部分,月底订购高峰时日订单量超过10万笔,客户对系统现状较为满意,希望能通过系统进行互联网营销活动,如红包、满减、直降、抢购等,大家都知道这些营销活动时用户请求将呈现指数级增长,我们评估目前的系统架构难以支撑此类需求。
当前系统是基于轻量级J2EE架构,大体上可分为两个子系统,订单处理子系统和接口子系统,因运营商的业务复杂、支撑系统众多,简单的流量包订购业务涉及多达6个系统提供的近10个接口,订单处理子系统的一部分工作就是调度后端系统接口完成业务需求;两个子系统间通过 Dubbo服务治理框架交互,订单处理子系统和接口子系统都是单体系统,分别部署了3个和5个节点,数据库为2台双机热备,前端接入采用一台 nginx 反向代理。
分析完系统现状后,我们分析了影响系统可靠性、扩展性的薄弱点:1、nginx 的单点失效风险;2、数据库的性能瓶颈; 3、单体应用中的服务雪崩风险,服务间未做隔离,很容易一个服务的问题影响到整个系统;4、快速交付要求下的系统部署风险,客户要求支持每周进行营销活动,目前架构下单体应用没有时间经过充分测试。
以上薄弱点中,nginx失效风险可以增加 nginx节点,前置负载均衡器解决;数据库性能瓶颈可通过订单处理异步化部分解决(只能缓解,仍存在瓶颈);服务雪崩和快速交付风险,甚至数据库瓶颈,我们考虑可以通过微服务架构解决。
微服务架构可以很完美的实现服务隔离,可以从物理上隔离服务占用的资源,配合降级机制可以较完美的解决服务雪崩风险;此外,配合良好的 Devops工具链,微服务系统可以单独发布影响到的服务,影响范围很容易控制,而营销活动时基本上都是独立开发一个或少数几个附加服务,对整体逻辑基本不影响,能很完美的达成快速交付目标;最后,进行促销活动的一般只有流量包等热点业务,微服务架构下我们可以将这些热点业务的订单数据库独立出来,甚至营销活动的服务独立数据库,然后通过 binglog 将订单数据同步到全订单库。
确定好微服务架构思路后,我们评估了当前微服务架构实现方案,出于平滑过渡、保护原有投资、工期等因素,最后我们决定采用 Dubbox方案实现, Dubbox 是当当网基于Dubbo2.5.3 继续开发的,增加了Restful、 Kyro等协议支持,具体设计方案及迁移路线图如下:
1、Dubbo2.5.3迁移到 Dubbox2.8.4,经灰度环境全面测试正常后,迁移生产环境。
2、构建容器环境:当前系统是运行在云平台上的,但云平台未提供容器服务,向运营商云平台申请资源,并与云平台协商,提供预装了容器环境的虚拟机镜像,我们项目新申请的资源统一使用此镜像。
3、搭建 Jenkins 工具链,测试 Devops自动化部署、自动化构建流水线,培训运维、开发人员掌握Devops 模式的开发部署流程,配合容器化环境实现性能高效扩展。
4、接口子系统拆分,在建立上述基础设施后,基本按每个接口一个服务方式拆分,同时每个服务内置超时处理和降级措施;因接口的逻辑相对简单,比较容易切分,考虑到处理性能且不直接对外,服务通过高效的kyro 协议交互。
5、订单子系统拆分,订单处理逻辑较为复杂,因此只考虑把热点业务拆分,每个热点业务的订单处理独立服务,本期只有流量包业务;且独立数据库,订单处理异步化,收单先入库到 redis中,同时记录文件日志以防万一时补偿;订单处理过程全部在通过 redis进行,同时另开同步线程池将脏订单数据入库到订单库;处理完的订单及时从 redis中清理,以降低 redis 持久化的开销;最后基于阿里巴巴Canal 将订单表同步到总订单库中。
按上述思路输出设计方案后,我们召集内外部专家、客户一起评审,大家基本认可此方案,补充部分细节后,经过近2个月的实施,系统成功上线,上线2年来,系统运行稳定,扩展性、可修改性、灵活性、可靠性、交付速度都得到大幅提高,得到客户一致好评,团队也经此一役得到锻炼,此后的微服务系统实施更为得心应手。
此项目的设计过程让我深深体会了架构师就是在各种方案间权衡这句话,要达到架构升级的目标不止这一种方案,不采用微服务,通过线程池隔离+异步处理+数据库集群也能基本解决问题,实施工期、实施风险也要小一些,但解决问题不够彻底,且难以达成客户提高交付速度的要求,但若工期、成本不允许的话也可能采用这种方案。通过此项目更能认识到架构师宽广的技术视野非常重要,要不断学习,跟进技术发展,以设计出更适合的架构,为各方创造最大价值。
评论区