论基于多层架构的系统设计

摘要

随着城市化进程的加快，城市管理面临越来越多的挑战，为了更好的解决城市管理中出现的各类问题，营造良好的人居环境，提高城市综合竞争力，国家住建部近年来在全国大力推广网格化城市管理新模式。我所在的公司是一家专门从事网格化城市管理信息系统研发的软件企业，我作为公司的技术骨干参与了多地网格化城市管理信息系统的调研、设计和开发工作。网格化城市管理系统是综合利用GIS、数据库、计算机网络等技术以工作流程管理为核心的信息化系统，笔者将在本文论述基于多层架构的网格化城市管理信息系统的设计方法、开发中遇到的问题和解决方法以及对系统未来发展的展望。

正文

由于城市化进程的加快，城市区域不断扩张，人口不断增长，日益增多的城市建设项目及人口流动带来了大量的城市管理问题，大到违法建设的拆除、市政设施的建设维护，小到流动摊贩和牛皮癣，城市各处都在不断发生着各种各样的问题，需要不同的城市管理职能部门及时发现处置。近年来全国数百个城市建设了网格化城市管理平台，通过平台的运行提升了问题的发现和处置效率，取得了良好的效果。

基础的网格化城市管理系统从功能上分为无线数据采集子系统、受理子系统、协同工作子系统、监督指挥子系统、地理编码子系统、基础数据管理子系统、应用维护子系统、综合评价子系统、数据交换子系统9大子系统。其中无线数据采集子系统是安装在手机上的APP软件，信息采集员使用该软件对巡查过程中发现的城市管理问题拍照、GPS定位并填写大小类、问题描述等各项信息，通过无线网络实时上传至服务器形成城市管理案卷。案卷进入系统后，用户使用其他子系统提供的各项功能，完成案卷的派遣、处置、督查、核查并最终结案，系统对案卷从上报至服务器开始进行全流程全时段监控，根据案卷流转信息和人员办理信息实时对案卷计算各项考评指标，最终生成对人员、岗位、部门、区域的绩效评价报表。

根据需求分析和各种体系结构的优缺点，我们最后决定采用B/S多层架构进行网格化城市管理系统的设计和开发。根据实际情况以及对未来电子政务的发展趋势预测，我们对传统的三层架构进行了调整，将网格化城市管理系统分为表现层、应用层、数据访问层、数据层4层。

表现层、应用层、数据层是传统的三层架构的分层方式。我们通过调研发现，市场上各类电子政务系统在数据库的选择上目前主要有MS SQL Server和Oracle两类。MySQL作为开源免费的数据库在互联网领域已经牢牢占据市场占有率第一的宝座，随着中央不断推进“互联网+”战略以及简政放权路线，未来极有可能MySQL也会越来越多应用于电子政务领域以降低项目成本和开发难度。

为了使系统能够支持MS SQL Server和Oracle数据库并在未来可以方便的扩展到更多数据库平台，我们在系统设计上增加了数据访问层，通过数据访问层屏蔽底层数据库平台的差异性，在更换数据库平台时，只需通过开发和配置对应的数据访问层，其他各层代码均无需修改，实现“热插拔”式平滑替换。下面详细介绍系统所选择的开发平台和各层的设计。

为了实现跨平台，系统选择Java作为开发语言，使用Spring完成对象管理、依赖注入以及数据访问。系统分为表现层、应用层、数据访问层和数据层，表现层负责数据的展示及用户交互，应用层负责业务功能的实现和各模块组织划分，数据访问层负责对数据库进行读写和完成数据格式转换，数据层负责数据的存储备份。系统架构如下图所示：

表示层基于ExtJS框架构建。当前RIA大行其道，B/S架构的系统前端在必须兼具美观的界面和良好的交互性的前提下，还需要考虑多浏览器兼容性以及对移动设备的支持，而使用JS技术构建前端界面可以很好的达到以上的需求。首先JS相比Flex、Silver Light等技术具有无需安装客户端插件的优势，使用JS实现的页面在浏览器打开即可直接呈现各类交互效果；其次JS与HTML5结合使用，可以实现跨平台的前端效果，无论是在PC端还是在Android、IOS、WP平台，都可以良好运行；最后由于开源运动蓬勃发展，目前有非常丰富的开源第三方JS开发库可用，能够帮助开发者快速完成交互、界面、网络、数据管理等各项基本开发工作。我司选择的ExtJS是业内主流的JS前端开发框架，ExtJS自带丰富的组件库，包括UI组件、数据组件、动画组件、网络访问组件等，同时提供了多套可直接使用的界面风格包，开发者可直接使用也可以扩展开发自定义界面风格。基于ExtJS构建的表示层使用Ajax与应用层进行数据交互，数据格式选择JSON，JSON是一种轻量级的数据交互格式，易于人阅读理解也易于机器解析和传输。

应用层基于Struts2开发，Struts2使用拦截器的机制处理请求，可以帮助完成数据过滤、基本路由等基本功能，开发者可专注于业务逻辑的实现而无需过多关注底层技术细节如请求、响应等。应用层的开发中，重点在于类的组织和数据交互接口的良好定义。类的设计要遵循高内聚低耦合的原则，通过合理的组织使得类之间能够相互协作完成各项功能，同时类的组织也应该能映射出子系统的逻辑划分。数据交互接口的定义也很重要，由于应用层是连接表示层和数据访问层的纽带，因此必须定义好与其他层的交互接口，包括输入参数输出参数的个数、类型、格式等，在提供给表示层调用的接口设计上，输入输出参数的格式均使用JSON格式，这样主流的JS框架如ExtJS、JQuery等都可以直接读取解析，便于将来功能扩展或更换前端组件。

数据访问层的目标是实现跨数据库平台。为了实现这一目标，我们首先根据应用层对数据的需要，抽象了一组数据访问接口，这组数据访问接口的输入输出参数类型均使用Java内置格式如List、Array等，这样对于应用层的开发者来说，无需了解数据库技术即可进行应用逻辑的开发。在设计好数据访问接口后，针对每种数据库平台，分别实现抽象数据访问接口开发配套的数据库访问对象，在数据库访问对象中处理不同数据库平台对数据类型、参数形式等差异性。应用层在与数据层交互时，面向接口编程而无需关注底层数据库平台细节。系统部署实施时，只需根据数据库平台配置对应的数据访问层即可。

数据层支持Oracle和MS SQL，在设计数据库对象时，尽量使用SQL标准中的数据类型及DML和DDL语法，以此来尽量实现代码和对象复用，减少在迁移到不同数据库平台时需要的定制开发工作量，降低开发者的学习难度。

系统开发中使用Spring来进行对象管理和依赖注入，提高了系统的稳定性和可配置性，避免Java开发经常遇到的内存泄露问题。系统使用了数据库连接池技术，实现了对数据库的高效利用，降低了资源开销提升了性能和可用性。

本项目开发完成后，与以往项目比较，开发周期明细缩短，软件稳定性、扩展性和可维护性明显提高，用户在使用中对系统表示一致认可。通过本次开发实践，我认为多层架构的系统设计和开发能够有效提高软件质量和开发效率。

第二篇：系统架构师论文-论微服务架构及其应用

论微服务架构及其应用

摘要

2016年7月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作，该项目是基于互联网，为单位、企业和个人等公众群体提供7*24小时的查询申请服务，同时兼顾行贿犯罪预防宣传。本文结合作者的实践，以行贿犯罪档案互联网查询系统为例，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该系统是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。经过项目组近一年的努力，本产品已顺利开发完成，目前，已在浙江、云南等多省上线使用，取得客户和公司领导的一致好评。

正文

近年来，随着互联网行业的迅猛发展，公司或组织业务的不断扩张，需求的快速变化以及用户量的不断增加，传统的单块（Monolithic）软件架构面临着越来越多的挑战，已逐渐无法适应互联网时代对软件的要求。在这一背景下，微服务架构模式(Microservice Architecture Pattern)逐渐流行。它强调将单一业务功能开发成微服务的形式，每个微服务运行在一个进程中；采用HTTP等通信协议和轻量级API实现微服务之间的协作与通信。这些微服务可以使用不同的开发语言以及不同数据存储技术，能够通过自动化部署工具独立发布，并保持最低限制的集中式管理。

2015年7月，我所在的公司为全国各级人民检察院开发了行贿犯罪档案互联网查询系统的产品，我担任系统架构师职务，主要负责软件架构和安全体系设计的工作。本文结合作者的实践，论述微服务架构及其应用。首先概述我参与管理和开发，并采用微服务架构开发的工作，然后具体描述微服务架构的特点，最后结合项目描述软件的架构，说明该架构是如何采用微服务架构模式的，并说明采用微服务架构模式后，在软件开发过程中遇到的实际问题和解决方案。

项目概述

随着互联网的飞速发展，基于互联网平台建设行贿犯罪档案查询系统（Internet Bribery Crime Record Query IBCRQ），为单位、企业和个人等公众群体提供实时、高效、方便的申请查询服务，是互联网+智慧检察的深度融合，也是社会经济发展的必然趋势。IBCRQ系统的建设，作为政府采购和招标审查的必经关口，将有行贿犯罪记录者拒之“门”外，大大降低了政府采购、工程建设等领域官商勾结、权钱交易的几率，为有效预防贿赂、震慑犯罪提供了很好的积极作用。IBCRQ系统包括用户注册、个人查询申请、单位查询申请、集中查询申请、异议复核申请、排号管理、法律知识问答、数据交换等业务模块，实际使用时，用户可根据实际情况的需要选择是否需要用户注册、排号管理、法律知识问答等模块自由组合，限于篇幅，在此我们不再详细介绍各个模块的功能。

微服务的目的是充分地分解应用程序以促进敏捷开发和部署。在IBCRQ系统项目的管理和开发中，我们按功能需求将系统划分为用户中心、查询申请、数据交换、预约排号、法律知识问答5个微服务，同时将项目团队划分为3个小组，根据功能的轻重缓急和工作量，安排各个微服务的研发。每个小组负责一个或多个组件完整的生命周期， 即服务谁开发，服务谁运营。 最后各个服务组件通过RESTful HTTP协议和消息路由功能进行服务组装。

微服务架构的特点

传统的单块软件架构在构建部署和扩展伸缩方面有很大的局限性，传统的单块架构一般分为客户端用户界面、数据库、服务端应用程序三部分。系统中任何程序的改变都需要整个应用重新构建和部署新版本。另外传统的单块软件架构在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。而微服务架构可以完美的解决统一风格架构所遇到的种种问题。微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立，单一功能的改变只需要重新构建部署相应的服务即可。与单块架构相比，微服务架构有如下的特点：

1)通过服务实现应用的组件化(Componentization Via Services)，在应用架构设计中，通过将整体应用切分成可独立部署及升级的微服务方式，进行组件化设计。

2)围绕业务能力组织服务(Organized Around Business Capabilities)，微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大。

3)基础设施自动化(Infrastructure Automation)，云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。

4)故障处理设计(Design For Failure)，微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此微服务非常重视建立架构及业务相关指标的实时监控和日志机制。

5)演进式的设计(Evolutionary Design)，微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。

微服务架构应用

在IBCRQ系统中，采用通讯层、业务逻辑层、基础服务层组成系统的微服务架构。如下图所示：

IBCRQ系统微服务框架

在微服务架构下，我们选择RESTful的进行通讯。每个微服务都统一对外提供REST服务。无论前端调用后端服务还是后端之间的服务调用都统一走RESTful，这样就统一了协议栈。微服务架构可以支持各种异构系统服务间的交互。

服务的注册与发现,服务之间需要创建一种服务发现机制，用于帮助服务之间互相感知彼此的存在。服务启动时会将自身的服务信息注册到注册中心，并订阅自己需要消费的服务。

负载均衡是服务高可用的保证手段，为了保证高可用，每一个微服务都需要部署多个服务实例来提供服务。我们主要支持随机、轮询、最少链接数的策略将来自网络的请求随机分配给内部中的多个服务器。

目前主流的RPC框架包括dubbo，thrift，grpc等，我们采用dubbo为团队提供了一整套序列化，反序列化，网络框架，连接池，线程池超时处理等业务处理之外的能力。

服务容错采用快速失败，失效切换的策略。如果连续失败多次则直接熔断，不再发起调用。这样可以避免一个服务异常拖垮所有依赖于他的服务。

遇到的问题及解决方案

在微服务实践中，我们主要遇到三个问题，一运维开销及成本增加，因为每个微服务需独立运行，还可能采用多种语言环境，这将导致资源开销大；二代部分码重复，某些底层功能需要被多个服务所用；第三个问题是难以可视化及全面测试，在动态环境下服务间的交互会产生非常微妙的行为。因此，首先服务划分应尽量合理，不要划分太细太多，其次采用公共模块的方式提供底层服务，再次微服务可通过监控发现生产环境的异常，进而快速回滚，弥补可测性不足的问题。

通过项目实践证明，实施微服务架构收益会大于成本。在拥抱微服务之前，也需要认清它所带来的挑战。需要避免为了“微服务”而“微服务”。对传统企业而言，开始时可以考虑引入部分合适的微服务架构原则，对已有系统进行改造或新建微服务应用，逐步探索及积累微服务架构经验，而非全盘实施微服务架构。

张建刚 2017年10月03日