论多层分布式结构系统的开发

论多层分布式结构系统的开发

摘要：

        2015年初，我所在的公司承担了某集团公司的移动信息化开放平台的建设工作。我在该项目中担任系统架构设计师的职务，主要负责设计平台系统架构和安全体系架构。该平台以移动信息化发展为契机，采用”平台+应用”的模式解决现有应用的集中移动化需求。平台整体的逻辑复杂，对系统的高可用和高扩展能力提出了较高的要求。

本文以平台系统架构为例，讨论了多层分布式系统的开发。在该项目的分布式C/A/S结构中，我在业务逻辑层引入了采用二次分发方式的接入层，实现了的具有会话保持要求的高并发请求处理，并通过数据库连接池、读写分离和主从分布式数据库完成了数据访问层的高可用设计。平台的研发耗时10个月，目前，系统已稳定运行了近两年时间，实践证明，我所采用的这些方法与工具在多层分布式系统的开发和运行中发挥了重要作用。

正文：

        随着移动信息化技术的迅猛发展，我所在的某集团公司的在信息化建设中发现，随着业务系统移动化的需求越来越多，内部移动应用的数量也随之激增，使用起来十分繁琐。为了解决这一问题，集团制定了移动信息化发展战略，根据这一战略要求，移动信息化开放平台应运而生。2015年初，我所在的分公司承担了集团移动信息化开放平台(以下简称MIOP)的建设工作，我有幸参与了项目前期的一些工作，担任系统架构设计师的职务，主要负责设计平台系统架构和安全体系架构。MIOP采用”平台+应用”的模式，立足于集团总部管理域各应用，覆盖全国各省分应用，实现移动应用的统一入口、统一认证、统一鉴权、统一管理，将总部与省分的各种有移动化需要的应用进行有效整合，降低了集团内部移动应用的使用难度，使用户可以无感知的在多个应用间进行切换使用。平台的主要用户是集团全国40多万管理域员工，其中首要保障的是集团领导和省分领导对移动应用的使用，其中涉及公文管理、合同管理、财务报账、ERP和CRM等多个复杂系统，业务流程复杂，系统可靠度和可扩展性要求较高，影响的范围比较广。在部署模式上，MIOP采用集团统一私有云集中部署，各省分系统与MIOP做网络对接，是一个典型的跨城际系统。在系统认证上采用既有4A系统结合自建应用商店作为权限入口，对使用者的权限进行划分。

        为了满足集团管理域40万用户的使用，我在与传统的单层或双层架构比较之后，首先将目光锁定了具有高安全性、高承载能力和高可用性的多层分布式系统。多层分布式系统主要由表现层、业务逻辑层和数据访问层构成，根据表现层技术的不同，多层分布式系统主要可以分为C/A/S结构和B/A/S结构两种，两者在业务逻辑层和数据访问层的实现比较接近，最大的区别在于C/A/S结构需要在用户终端安装客户端程序实现表现层，而B/A/S结构通过用户终端的浏览器作为表现层，无需额外安装客户端。从实现效果比较，B/A/S的表现层受到用户终端浏览器和通信方式的限制，性能和表现能力方面不如C/A/S结构。考虑到平台的主要业务是移动信息化应用集成，表现层采用移动终端的原生应用开发，既可以达到超越浏览器能力的表现效果，又可以满足用户使用上的性能需要，我最终选择了分布式C/A/S结构作为系统的主要架构。

        多层分布式系统的业务逻辑层首先要解决的问题是请求数据的分发问题。为了解决这个问题，我首先在业务逻辑层引入了接入层的概念，接入层与下方的业务处理服务形成了一种主从的分布式结构，接入层负责来自表现层的业务请求的分发，各业务处理服务对请求进行加工处理，并通过接入层将处理结果返回给表现层的客户端。在接入层的设计上，虽然平台部署环境具有硬件负载均衡设备可以解决压力分配问题，但是平台业务中存在必须保持用户会话的业务处理，而部署环境的硬件负载均衡设备并不支持应用的会话保持，这就造成了如果单纯的采用硬件负载均衡设备作接入将无法实现系统需求的问题。为了解决这个问题，我通过调研发现，比较成熟的Web服务软件如nginx、apache等都可以通过反向代理实现具有会话保持能力的负载均衡，而nginx在部署环境的linux系统中的负载能力表现更为突出，于是我采用了接入层二次分发的方式实现业务需要，将硬件负载均衡作客户端的直接接入，将客户端的请求分发给下级的软件负载均衡，以解决业务逻辑层的并发压力和请求分发问题，软件负载均衡，也就是nginx，再对请求进行二次分发，满足业务中的会话保持要求。这样，在业务逻辑层的接入层就形成了既有会话保持能力又有高并发分发能力的接入层，结合业务逻辑层的分布式业务处理服务实现了系统业务处理的高可用和高扩展性。

        与业务逻辑层不同，数据访问层首先要解决的是数据库的连接数问题。数据库系统由其设计特点和运行环境决定，单机的连接数是有上限的，一旦达到这个上限就有可能造成数据库系统故障，进而导致整个系统业务瘫痪。因为业务逻辑层采用分布式结构，各处理节点的业务相对独立、无相关性，实际上在接入层之后形成了一套并行分布式系统，业务逻辑层的最下层数据交换服务需要直接与数据库交换数据，随着数据交换服务的节点增多，数据库的承载能力再次成为系统的瓶颈。如果每个交换节点的数据库连接数不进行控制，数据库系统的连接能力得不到提高，系统将无法满足高并发和高扩展能力的需要。针对这一问题，我在数据交换服务中采用了数据库连接池的技术，每个数据交换服务不会无限制的扩展连接数，而是以固定的连接池大小为限，使用有限的数据库连接，这样就可以使得数据库所要面对的连接数不再是一个未知的无限大的可能。同时，我根据系统数据业务读多写少的特点，采用了基于主从结构的分布式数据库系统，数据库系统由一个主节点和若干各从节点组成，并采用了读写分离技术提高系统性能。正常服务时，主节点仅接受写操作，从节点仅接受读操作，主节点的每次写库都会将结果同步到各个从节点以保持一致性，当主节点发生故障无法提供服务时，从节点通过表决重新选出一个从节点自动接替主节点继续工作。这样，通过增加数据库系统的从节点就可以支持更多的数据库访问需要，同时兼顾了数据访问层的性能要求。

        采用了这些技术手段之后，我所设计的这种架构得到了集团领导的认可和采纳， 2015年末，MIOP正式上线运行，至今已稳定运行了接近2年时间。我为实现平台的分布式C/A/S结构所采用的接入层二次分发机制、数据库连接池和读写分离技术、主从分布式数据库等方法和策略，在系统的开发和运行中都发挥了重要的作用，获得了领导和同事的好评。但是在系统运行过程中，我也发现了这些技术和工具存在的一些不足。首先是接入层的二次分发实际占用了多余的带宽，并损失了部分性能。其次是数据库系统扩展节点时需要数据库连接部分随之修改地址表，使得系统需要较短的时间来重启数据交换服务，会短暂降低系统的可靠度。这些都将是今后我进行架构设计时需要进一步考虑的问题。

最后

以上就是笨笨画板为你收集整理的论多层分布式结构系统的开发的全部内容，希望文章能够帮你解决论多层分布式结构系统的开发所遇到的程序开发问题。

如果觉得靠谱客网站的内容还不错，欢迎将靠谱客网站推荐给程序员好友。