论架构风格及其应用

        2017年2月，我司承接了一套虚拟运营商平台管理系统项目，需要对系统进行设计与应用开发。系统主要包含号卡计费功能、号卡风控管理、财务系统、ISP数据交互功能、营销后台功能以及支撑运营人员进行日常工作的常用功能等。我在项目中担任技术负责人一职，主要负责架构设计与考量工作。系统架构风格的选择对于后期保证系统的可扩展性、稳定性以及易修改性都起到关键性的作用。因此，我们从三个层面选择了不同的架构风格进行设计。表现层，我们主要考虑减轻客户端程序更新负担以及系统使用的便捷性，采用B/S架构风格。业务层，为了减少系统耦合性以及提升开发效率，我们采用MVC架构进行设计。服务层，为了提高各模块服务的可复用性，我们采用了微服务架构进行设计。项目如期顺利上线，获得了用户的一致好评！

        为了打破电信行业的自然垄断，增加电信市场的竞争力，工信部于2013年向各类相关企业颁发了电信虚拟运营商牌照。我们受甲方公司委托，于2017年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个月的时间，项目于2018年3月正式上线，项目稳定运行至今已4年时间有余，期间无重大故障问题，可用性达到了99.99%，获得了用户的一致好评。项目过程中也遇到一些难题，例如微服务分布式事务问题，最后，我们使用基于MQ消息队列的方式得到了难点的解决。通过该项目的应用与实践，我们积累了架构风格选择与应用的宝贵经验，希望以后再接再厉，将这些经验利用到位，争取做出更加高质量的软件系统!