e-works数字化企业网  »  文章频道  »  基础信息化  »  网络与安全

一套大而全的系统架构体系与具体落地方案

2018/1/22    来源:搜狐    作者:战学超      
关键字:系统访问链路  数据中心  
本文从系统访问链路为切入点,围绕访问链路的方方面面,包括基础设施、分层架构、分割架构、系统保障、技术平台生态圈等几个方面进行展开,同时结合自身经验,介绍具体落地的方案和技术,希望能够给读者带来一些收获。

    当然也有一些企业因为自身数据的保密性比较高,业务相对比较特殊,所以一开始就自建数据中心机房。
 
    一般而言,数据中心机房的建设要按照国家标准和行业标准进行建立,这都有比较明确的标准规范,这里大概总结了一下:
 
一套大而全的系统架构体系与具体落地方案
 
    数据中心的建立有自建或是委托专业数据中心设计公司来进行。一般公司可以通过第二种方式,通过与专业的数据中心设计公司合作,建设安全、可靠、伸缩性强以及节能环保的数据中心。
 
    另外数据中心的建立、验收、等级、灾备等都有着明确的国家规范和行业行规,大家在规划或建立的时候,一定在合规的底线上,进行优化设计,常用的数据中心参考文档有:
 
    《数据中心建设与管理指南》
 
    《GB50174-2017 数据中心设计规范》
 
    《GB50462-2015数据中心基础设施施工及验收规范》
 
    《GBT22239—2008信息系统安全等级保护基本要求》
 
    TIA-942《数据中心电信基础设施标准》(中文版)等等
 
    【提示】由于文档打包较大,感兴趣的同学可点击链接https://pan.baidu.com/s/1eR7RyPO或点击文末【链接】进行下载。
 
    4、基础设施管理与优化
 
    1基础设施管理
 
    对于基础设施的管理,需要CMDB结合资产管理系统对基础设施进行统一录入、上架、管理、下架、报废等全生命周期进行管理。通过IT系统进行基础设施管理,可以提高管理效率,降低故障率等。CMDB作为运维管理体系中的基础一环,至关重要。一些中小型企业可能暂时没有能力建立或是购买CMDB,这时可以通过采用构建开源CMDB或是直接用最简单有效的Excel进行管理,总之,不管哪种方式,基础设施的集中管理不可或缺。CMDB中的数据一定要与实际环境实时对应,确保准确无延迟。
 
一套大而全的系统架构体系与具体落地方案
 
    2基础设施优化
 
    为了更高效地利用基础设施的资源,虚拟化、容器化正在不同的公司中逐渐实行。本文以一些中小公司(包括我们公司)常见的基础架构演变路线进行介绍。
 
一套大而全的系统架构体系与具体落地方案
 
    很多公司遵循着多台物理机到虚拟化再到容器化或是虚拟化容器化并存,最终实现到云服务的这一演变过程。首先是初始阶段的多台物理机部署服务,资源利用率比较粗,相对比较浪费,于是通过虚拟化提高资源的利用率和管理效率。我所经历的一家公司正处在虚拟化阶段,通过购买fc-san存储,构建虚拟化集群,实现服务器的高效利用、集群高可用并且便于备份。但在虚拟化的过程中,也经历着虚拟化的以下问题:
 
    搭建成本太高,需要购买专业存储以及网络设备等。(当然也可以直接在物理机上部署exsi,但是高可用不是很好实现,例如VMare自带的高可用组件)
 
    虚拟机备份比较笨重,需要结合BE或是自带的备份工具,耗时较长,备份粒度不够细。
 
    服务宕机后虚拟机漂移时间相对较长,大概5分钟左右(跟硬件和技术有关系,有的公司可能时间很短)。漂移后虚拟机自动重启,如果部署在虚拟机上的服务未开机自启,将比较头疼。
 
    部署虚拟机时间较长,虽然采用Cobbler等方式实现自动安装,但部署一套虚拟机,大概在10~20分钟左右。
 
    以上四点是我们在做虚拟化时,面临着比较突出的问题,当然这也许跟我们虚拟化工程师的技术水平有一定的关系。为了解决虚拟化的问题,提高运维效率,我们现在正进行虚拟化+容器化并存的架构改进和优化,当前架构如下:
 
一套大而全的系统架构体系与具体落地方案
 
    注:基础设施架构这一块,目前我们面临这1~2年后的数据中心迁移以及新数据中心规划,后续我们的规范方案和迁移方案定稿后,会继续跟大家分享、探讨。
 
    可以看出,当前基础资源架构是虚拟化和容器化并存,二者相互隔离又在应用层面相互联系,共同组成集群,为上层应用提供服务。
 
    相比虚拟化以及物理机,单纯容器化有以下几个难点不太好实现:
 
    Windows服务器在Docker容器不能或是不容易部署。(据称Docker已经开始支持win,但未研究测试)
 
    Oracle数据库在Docker部署缺少大规模生产经验,不敢贸然直接在容器部署Oracle服务器。尤其是RAC+DG这样的高可用集群,在容器部署也不太现实。
 
    就目前我们技术现状来说,单纯容器化有一定的风险,需要一个摸索阶段,虽然有很多成熟的经验可以借鉴,但毕竟适合自己的架构才是最好的。
 
    基于容器的便利性以及高效快捷,未来会逐渐以容器化为主,但数据库和Window服务相关的部署以虚拟化为主,二者互补,为以后实现云服务提供基础铺垫。
 
    容器化管理计划以K8s为主进行编排和调度,K8s目前正在技术调研和测试中,待成熟后会为大家继续进行分享。当然我们也面临着是否需要采用OpenStack或是其它技术搭建IaaS基础云平台的纠结。
 
    不管系统架构还是基础架构,都是一个逐渐演化的过程,适合当下业务架构并且易伸缩的架构才是最优化的架构。
 
    三、分层架构
 
    1 、分层架构概述
 
    系统在做分层架构候,一般情况下主要包括:接入层、应用层、公共服务层、数据存储层等几个层次,其中接入层还包括DNS转发、CDN、负载均衡层、静态资源层等。有CDN的公司会直接将静态资源放在CDN层中。
 
    系统分层架构图大概如下:
 
一套大而全的系统架构体系与具体落地方案
 
    2、负载均衡和反向代理
 
    负载均衡分为软负载和硬负载。其中硬负载包括有F5、A10等不同品牌的硬件负载均衡器,软负载包括LVS、Nginx、HAproxy等开源软负载均衡软件。硬负载相对比较贵,成本较高。中小企业可以选择开源的软负载实现负载均衡和反向代理,通过负载均衡提高系统的吞吐从而提高性能,反向代理增加内部系统的安全性。负载均衡服务器一般是部署在DMZ区域与内网通过防火墙进行端口映射,提高内网服务器的安全。
 
    软负载的选择上一般从LVS、Nginx、HAproxy三者中进行选择或是组合选择。其中LVS相比Nginx、HAproxy、LVS工作在网络四层,仅做请求转发,性能效率比较高。Nginx和HAproxy工作在网络七层之上,较LVS性能差一些,但二者之间,并没有特别大的差别。
 
    使用负载均衡和反向代理一般要着重考虑以下三个问题:
 
    高可用问题
 
    负载策略
 
    有状态服务的session保存
 
    (1)实现负载均衡服务器的高可用一般通过虚拟IP的方式,将虚拟IP通过防火墙与公网IP端口转换,对外提供服务,常用的开源组件有keepalived。但在使用开源组件进行虚拟IP配置时,一般都要去积极主动地进行脑裂检测和避免脑裂问题的产生。通常用检测脑裂问题的办法进行仲裁,通过多个节点进行仲裁选举出问题节点,踢出集群,我们在做脑裂仲裁时除了其它节点选举之外,还添加本节点的自动检测,避免本节点故障假死的情况下,选举不准确。关于脑裂仲裁算法网上都有实现方法,大伙可以参照,结合实际情况进行改良。
 
一套大而全的系统架构体系与具体落地方案
 
    (2)使用负载均衡和反向代理有一个比较重要的问题就是负载策略的选择。以Nginx为例,常用的有Round-robin(轮循)、Weight-round-robin(带权轮循)、Ip-hash(Ip哈希),其中HAproxy还支持动态加权轮循(Dynamic Round Robin),加权源地址哈希(Weighted Source Hash),加权URL哈希和加权参数哈希(Weighted Parameter Hash)等。但是我们生产环境中用的最多的还是轮询和iphash这两种方式。如果后端应用是有状态的,且未实现session共享,一般使用ip-hash的方式。
 
    (3)对于有状态的后端应用,如果采用轮询的策略会有问题。但是采用ip-hash的方式也会有一定的问题,首先是后端服务器的访问负载不均衡,会有较大的偏差,其次是未实现真正的应用高可用,当连接到的后端服务器宕机,session丢失,需要重新进行业务登录或操作等。解决这一问题一般常用的方法有三种:
 
    应用服务器共享session
 
    cookie存session
 
    session服务器存session
 
    应用服务器共享session,这个Tomcat是支持的,只需要配置即可,但对应用的性能有比较大的影响,尤其是应用节点比较多的情况;cookie存session是一个方法,但cookie的大小有限,不适合存较多的session;session服务器存session应该算是最佳的办法,例如使用Redis存共享session,很多公司在用,但也有一个缺点就是增加维护成本和运维复杂度,虽然这项技术实施起来会比较简单。
 
    3、业务应用层
 
    业务应用层比较大的一块是做服务化,这会在下面的分割架构进行详细说明。这里主要说明简单的业务拆分和应用集群的部署方式。
 
    高内聚、低耦合一直是软件开发和系统运维所积极追求的。通过实现业务系统的高内聚、低耦合,降低系统依赖,提高系统的可用性,降低故障率,业务拆分是解耦的重要利器之一。一般根据公司业务系统的特点和关联进行拆分,对公共业务系统进行抽取形成公共业务应用,对所有业务系统进行接口化服务。各个业务系统之间独立部署,降低耦合度,减少了业务系统之间的依赖和影响,提高整个系统的利用率。
 
    因为有前面的负载均衡和反向代理层,所有后端的应用服务器可以横向部署多台,实现高可用也起到用户访问分流,增加吞吐、提高并发量。实际应用部署中主要以Java应用居多,且多部署在Tomcat中,以此为例,在应用服务器部署时,主要考虑以下几个问题或是建议:
 
    统一JDK和Tomcat版本。这很重要,主要是为了方便管理,另外也方便做自动化运维部署。其中统一部署中的操作系统优化、安全加固,Tomcat优化、安全加固等都要做好,我们在做Tomcat自动部署的时候,采用的是根据系统配置自动优化的方式和安全加固策略进行。另外就是自动备份和日志的自动切割,都在统一部署脚本中体现。这样所有部署下来,安装位置、部署方式等都是一致的,方便统一管理,统一备份和升级。
 
    动态页面静态化。这个根据访问量选择系统进行,例如公司的B2C官网等可以采用静态化的技术,提高页面的访问速度。
 
    4、公共服务层
 
    公共服务层将上层业务层公共用到的一些缓存、消息队列、session、文件图片、统一调度、定时任务等抽取出来,作为单独的服务进行部署,为业务层提供缓存、消息队列以及图片等服务。
 
一套大而全的系统架构体系与具体落地方案
 
    缓存主要是指的缓存数据。应用服务器通过缓存服务器查询常用数据,提高系统的查询速度,对于高并发的写,通过异步调用消息队列,进行数据的临时存储,提高系统的并发量和系统效率。Session集群以及文件图片服务器集群主要是为上层业务应用提供统一的session存储和图片文件存储的,避免系统的session失效和单点故障。
 
    常用的数据缓存以及session存储主要是Redis。Redis的集群部署方式在数据存储层会详细说明。
 
    消息队列的主要中间件有ActiveMQ和RabbitMQ等,二者都提供master-slave或是集群的部署方式。我所经历的公司中二者都有生产上的应用。常用的还有ZeroMQ、Kafka,但ZeroMQ不能持久化存储,因为并未在生产使用,所以不好多说。Kafka主要在搭建日志分析平台时用到过。对于ActiveMQ和RabbitMQ,二者并没有太大的区别,都在生产用过,也没遇到太大问题。在技术选择中,还是选择开发和运维最熟悉的为好,再具体点,建议以开发最熟悉的为标准。

责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐