2月,我司承接了一套虚拟运营商平台管理系统项目,需要对系统进行设计与应用开发。系统主要包含号卡计费功能、号卡风控管理、财务系统、ISP数据交互功能、营销后台功能以及支撑运营人员进行日常工作的常用功能等。我在项目中担任技术负责人一职,主要负责架构设计与考量工作。系统架构风格的选择对于后期保证系统的可扩展性、稳定性以及易修改性都起到关键性的作用。因此,我们从三个层面选择了不同的架构风格进行设计。表现层,我们主要考虑减轻客户端程序更新负担以及系统使用的便捷性,采用B/S架构风格。业务层,为了减少系统耦合性以及提升开发效率,我们采用MVC架构进行设计。服务层,为了提高各模块服务的可复用性,我们采用了微服务架构进行设计。项目如期顺利上线,获得了用户的一致好评!
为了打破电信行业的自然垄断,增加电信市场的竞争力,工信部于向各类相关企业颁发了电信虚拟运营商牌照。我们受甲方公司委托,于2月承接了一套虚拟运营商平台管理系统项目,进行系统设计与应用开发,支撑甲方公司开展相应业务。系统主要包含号卡计费功能、号卡风控管理、财务系统、ISP数据交互功能、营销后台功能以及支撑运营人员进行日常工作的常用功能等。系统大部分使用场景都是客户基于使用浏览器,通过网络访问的方式对系统进行数据查询与相关操作。数据交互方面则更多的是与ISP运营商的号卡数据交互以及相关财务往来等。我在项目中担任技术负责人一职,主要负责架构设计与考量工作。面对新系统的开发设计,架构风格选项必然对系统的可扩展性、稳定性与可维护性起到关键性作用。基于项目的实际情况与需求背景,我们也初步提炼出了一些架构风格的选型,例如该系统大部分用户都是通过浏览器方式访问系统,那么我们首先考虑到的是表现层可以使用B/S架构风格。再例号卡风控模块、号卡营销后台管理模块等,后期有可能以SaaS的方式作为独立产品进行发布,此时我们服务层可以将微服务架构纳入考虑范围等等。以上只是最初进行架构风格选择的初步思路,为了更加谨慎地对架构进行选择,我们需要了解架构风格的更多内容。
软件架构风格是描述某一特定应用领域系统组织方式的惯用模式。软件架构风格定义了一个系统家族,即一个软件架构定义一个词汇表和一组约束,词汇表中包含了一些构件和连接件类型,而这组约束指出系统是如何将这些构件和连接器组合起来的。软件架构风格反映了领域中众多系统所共有的结构和语义特性,并指导如何将各个模块和子系统有效地组织成一个完整的系统。
软件架构风格大致为5种风格,其中又会包含相关子风格。
1.数据流风格。该风格强调数据以流的方式,数据经过一个构件的处理输出作为下一个构件的输入。其中包括2个常见子风格:批处理与管道-过滤器风格。
2.调用返回风格。该风格强调结构分层,上层通过接口调用或者系统调用等方式,最后从下层获取到处理结果。其中包括常见子风格,主程序/子程序、面向对象、B/S分层架构、MVC分层架构、层次架构等。
3. 独立构件风格。该风格强调整个系统应该是通过构件和连接器组合而成,适用于模块化程度较高的系统。其中包括常见的风格如,进程通信风格、事件驱动(隐式调用)风格、微服务架构风格等。
4.虚拟机风格。该风格强调支出用户自定义规则、语法等,灵活的实现相关系统功能。
其中包括2个常见子风格,解释器风格与基于规则的系统风格。
5.仓库风格。该风格强调以数据为中央数据为核心进行设计。其中常见的3种子风格包括数据库风格、黑板风格以及超文本系统风格。
综合对软件架构风格的特点分析与实际项目需求情况,以本项目为例,下文将从三个系统层面:表现层,业务层,服务层,及各层面所采用具体架构风格设计与应用的过程进行阐述。
一.表现层
表现层方面,我们综合需求方的需求情况,最终决定使用B/S架构风格进行系统设计与应用。B/S架构的优势是,针对用户而言,用户对系统的更新是无感的,用户无须担心系统更新问题,不需要更新客户端,减轻了用户的负担。并且,基于B/S架构具有良好的跨平台性,无论是Linux操作系统、MacOS系统还是Windows操作系统,都能直接通过浏览器进行使用。针对开发人员而言,也能减轻相应工作量,无须开发特定客户端,只需要专心进行后端系统的开发工作即可。系统的大部分用户都是PC电脑进行办公,十分符合B/S架构的特点。用户无须安装特定的客户端,直接通过PC电脑浏览器就能使用系统,用户很快就能对系统上手,减少针对特定客户端,用户使用培训与引导成本。项目组也无须招聘额外客户端开发人员,减少了整个项目的人员成本与费用开支。
二.业务层
业务层方面,我们结合技术团队的技术栈与结构考虑,最终选定使用MVC架构进行设计与应用。MVC架构中,M是指Model模型、V是指View视图、C是指Controller控制器。用户从View视图页面提交表单请求到系统,系统的Controller控制器拿到请求相关数据后进行相关路由处理到对应的Model模型,Model模型收到业务数据够进行业务逻辑处理,最终将结果传递给View视图进行内容响应,客户端从View视图中获得最终的结果。MVC的分层结构,职责划定明确,层次结构清晰,耦合度低,容易排查问题与调试。例如项目组中,做前端页面的开发人员只负责视图View的渲染与显示,无须关心Model模型的实现逻辑与工作内容,同样的Model只需要关心Controller控制器传递过来的业务数据,并且进行处理,数据处理结束够直接传递到View视图,不关心相关页面渲染和排版情况。各自提高了开发的工作效率,同时也能将职责进行有效划分,避免无效的沟通与争执。
三.服务层
服务层方面,我们考虑到需求方后期存在会将某些业务模块如号卡风控模块、号卡营销后台管理等进行独立部署与产品化的可能性,我们最终选定使用微服务架构风格来进行设计与实现。微服务架构强调将粗粒度的服务模块,拆分为更小粒度的微服务,各微服务能够由于独立的运行环境,相互之间不会影响。同时支持技术异构性的特点,各微服务可以针对特定主业务场景选用不用的技术选型方案。我们将号卡风控管理模块、号卡计费模块等进行微服务拆分,使得这些微服务的职责更为单一,降低了服务的复杂性,减少了各微服务之间的耦合。同时针对不同模块的关注点不同,我们的微服务选用了不同的技术选型。例如号卡的风控管理模块,该模块强调高性能,短时间之内能做出响应。我们后端开发微服务就采用了J2EE技术进行实现,由于Java的技术生态与组件的相对完整性,使用该技术无疑是和服务关注点十分贴近的。针对号卡营销后台管理服务,该模块服务强调更新与迭代速度,但是对性能要求不是很高。我们则选用了PHP动态脚本的技术选型进行设计与开发,相对其他静态编译型语言选型,开发速度更快,短时间就能实现功能需求的开发与实现。
历经13个月的时间,项目于3月正式上线,项目稳定运行至今已4年时间有余,期间无重大故障问题,可用性达到了99.99%,获得了用户的一致好评。项目过程中也遇到一些难题,例如微服务分布式事务问题,最后,我们使用基于MQ消息队列的方式得到了难点的解决。通过该项目的应用与实践,我们积累了架构风格选择与应用的宝贵经验,希望以后再接再厉,将这些经验利用到位,争取做出更加高质量的软件系统!