java分布式技术平台架构方案

1. CoolJava技术特点

   CoolJava的技术解决方案信息系统的稳定性、技术先进性、可拓展性，并且满足未来继续增长、业务变革、监管加强的潜在需求。追求系统快速开发迭代，CoolJava应用开发框架能3倍以上速度，完成系统开发。系统平台具有较大的灵活调整空间，当有新的主数据类型、新的数据需求、新的数据结构、新的数据接口及流程等需求时，整体系统架构不需要重新构建，通过可扩展的架构方式即可满足功能变化，前端数据录入可根据数据模型自动构建信息录入页面，后端数据输出灵活方便，与其它系统之间的接口易于修改和维护。

CoolJava系统平台采用先进的分布式微服务架构实现，利用容器化技术在实现集中部署，提供稳定、高效、灵活可扩展的高可用服务。

1. 技术架构

CoolJava系统平台采用先进的、与主流互联网公司相一致的分布式技术架构，以微服务架构为核心，整合关系型数据库、NoSQL 数据库、非结构化存储等数据存储方式，整合负载均衡、服务发现、动态路由等服务接入方式，整合桌面、浏览器、移动等多终端交互方式，提供稳定、独立、高效、灵活可扩展的系统服务。分布式技术架构将传统的应用层重构为基础服务层、业务服务层和接入层，新增大数据服务、微服务管理服务、智能服务、并发控制服务、数据服务等基础服务。CoolJava平台的系统逻辑架构主要包括存储层、业务服务层、接入层、等。如下图所示：

系统总体功能架构分为集成层、数据层、服务层、交互层。集成层提供与下游系统相关的数据接收、发送、监控等功能。

分布式技术架构的主要特点包括：分布式服务架构、分布式存储架构。分布式服务架构主要通过基础服务层、业务服务层、接入层实现，分布式存储架构主要通过基础服务层的数据服务、存储层实现，通过智能运维满足自动化部署、可视化运维，通过敏捷交付实现 DevOps 功能支持开发、测试、部署工作的流程化和自动化同时提供持续集成，用户单点登录通过用户层实现。

2.1分布式服务架构

 

CoolJava系统平台的分布式服务架构主要包括微服务架构、容器化部署、异步消息、统一缓存服务等四个方面。

通过采用微服务架构使CoolJava系统平台的应用利用 Docker  容器实现最佳部署。在容器化部署基础上，通过 Kubernetes 根据容器的 CPU、内存等指标对系统自动进行扩缩，从而实现根据资源使用情况动态调整的应用资源调度架构。微服务间调用通过 Kafaka异步消息服务实现异步调用机制，基于 Redis 的分布式缓存服务实现统一缓存管理。

2.1.1微服务架构

微服务作为系统架构的一种设计风格是目前最先进、主流的系统架构，其主旨要求每个微服务实现一项或一些耦合度较高的业务功能，各微服务之间通过协作完成完整的业务流程。

CoolJava系统平台的微服务基于 Spring Boot + Spring Cloud 框架构建，通过Eureka 实现微服务的自动注册与发现。CoolJava系统平台微服务构建的基本原则： 围绕系统的某一项或一些耦合度较高的服务功能进行构建，每个服务都维护着自身的数据存储、业务开发、自动化测试案例以及独立部署机制。

由于微服务之间通过基于 HTTP 的 RESTful API 进行通信协作，数据传输采用 JSON 格式，所以微服务架构使CoolJava系统平台具有良好的兼容性、灵活性、扩展性，支持快速使用新技术构建新的微服务。微服务架构相比传统单体架构还具有错误隔离性的优势，当某项微服务出现故障时不会影响整个系统的正常运行。

2.1.2容器化部署

CoolJava系统平台在采用微服务架构的基础上，通过 Docker、kubernetes  等实现CoolJava系统平台微服务的容器化部署，根据各微服务的资源（CPU、内存等） 使用情况对运行容器进行弹性伸缩，实现微服务资源占用的动态调配以及微服务器资源的合理分配。

 

CoolJava系统平台在进行容器化部署的基础上采用 Ingress 实现高可用负载均衡架构，为每项微服务构建指定的负载环境，每个负载实现主备之间自动切换以实现负载高可用。

2.1.3异步消息

CoolJava系统平台采用 Kafaka 等实现异步消息总线，微服务之间通过异步消息总线进行异步消息调用，通过微服务之间的异步消息机制实现应用解耦、流量削峰以及灵活扩展。

 

 

2.1.4统一缓存服务

CoolJava系统平台采用 Redis集群实现高可用分布式缓存服务，根据业务需求与系统监控情况，通过动态启用模型缓存、元数据缓存、主数据缓存、流程数据缓存， 系统会根据数据特点及缓存要求，确定缓存的方式与自动刷新的周期。

2.2分布式存储架构

CoolJava采用的分布式存储架构主要  有以下特点：

1. 扩展性和高性能：

Scale-Out 架构允许通过简单地增加资源来提高存储容量和性能，磁盘、计算和 I/O 资源都可以独立增加，支持 10GbE 和 InfiniBand 等高速网络互联。弹性哈希（ElasticHash）解除了对元数据服务器的需求，消除了单点故障和性能瓶颈，真正实现了并行化数据访问。

1. 高可用性

对文件进行自动复制，如镜像或多次复制，从而确保数据总是可以访问，甚至是在硬件故障的情况下也能正常访问。自我修复功能能够把数据恢复到正确的状态，而且修复是以增量的方式在后台执行，几乎不会产生性能负载。并且采用操作系统中主流标准的磁盘文件系统（如 XFS）来存储文件，因此数据可以使用各种标准工具进行复制和访问。

1. 弹性卷管理

据储存在逻辑卷中，逻辑卷可以从虚拟化的物理存储池进行独立逻辑划分而得到。存储服务器可以在线进行增加和移除，不会导致应用中断。逻辑卷可以在所有配置服务器中增长和缩减，可以在不同服务器迁移进行容量均衡，或者增加和移除系统。

2.3技术框架

CoolJava技术方案以 Spring  Cloud 为核心技术框架。Spring  Cloud 是目前业内比较成熟的、比较先进、应用最广的微服务架构解决方案之一。具有多领域、跨行业、广泛的成功案例，丰富的社区支持和开发人员。Spring  Cloud 的核心特性包括：分布式/版本化配置、服务注册和发现、路由、服务和服务之间的调、负载均衡、断路器、分布式消息传递等。

相对其它框架，它具有以下优势：

• Spring Cloud 来源于 Spring，质量、稳定性、持续性都有充分保障

• Spirng Cloud 天然支持 Spring Boot，更加便于业务落地

• Spring Cloud 发展迅速，拥有大量的社区、技术支持

• Spring Cloud 对微服务周边环境的支持力度最大Spring Cloud 是由多个组件构成的，其主要架构如下：

 

 

• Eureka

     Eureka 是 Spring Cloud 的最重要核心组件，负责服务的注与发现，提供了完整的Service Registry 和Service Discovery 实现。所有可以提供的服务都通过 Eureka 进行注册和管理，方便后续的水平扩展、故障转移等。同时 Eureka 提供均衡负载的功能和心跳检测机制。

• Hystrix

在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致      “服务消费者”的不可用,并将不可用逐渐放大的过程。 在这种情况下就需要整个服务机构具有故障隔离的功能，避免某一个服务挂掉影响全局，即 Spring Cloud 中 Hystrix 组件。Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。

• Hystrix dashboard,Turbine

负责监控 Hystrix 的熔断情况，并给予图形化的展示。

Hystrix-dashboard 是一款针对 Hystrix 进行实时监控的工具， 通 过 Hystrix Dashboard 我 们 可 以 直 观 地 看 到 各 Hystrix Command 的请求响应时间, 请求成功率等数据。

Turbine 负责汇总系统内多个服务的数据并通过 Hystrix Dashboard 显示。

• Spring Cloud Config

Spring Cloud Config 是一个解决分布式系统的配置管理方案, 提供统一的配置中心服务，解决了随着微服务增多引起的配置文件混乱。它包含了 Client 和 Server 两个部分，Server 提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client 通过接口获取数据、并依据此数据初始化自己的应用。

• Spring Cloud Bus

Spring Cloud Bus 是轻量级的通讯组件,通过轻量消息代理连接各个分布的节点，广播状态的变化（例如配置变化）或者其它的消息指令。当配置文件发生变化的时候，通知各服务去获取最新的配置信息。

• 网关服务

在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway 作为轻量级网关，同时 API Gateway 中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。Zuul 是 Spring Cloud 框架中 API Gateway 的落地实现，负责转发所有对外的请求和服务， 起到 API 网关的作用。

• 链路追踪、日志服务

随着服务的增多，调用链路的深度和广度都会成倍增加。对调用链的分析工作也就越发复杂。在 Spring Cloud 架构下，我们通过Sleuth+Zipkin 进行链路监控，记录所有的请求数据，方便我们进行后续分析。

2.4部署架构

2.4.1逻辑架构

CoolJava系统平台采用云环境发布，且综合考虑本项目所覆盖业务重要性程度， 要求整个系统在设计过程中必须保证较高的可用性，以保证重要应用具有较高的业务连续性。在系统物理架构的设计时需要遵循以下原则：

 

 

系统工具：

  定时任务、可视化报表、通用时间字符串处理、mapper文件自动加载，连接池监视、接口API，单元测试。

 

 

 

中间件：

  消息队列kafa/zookeeper，分布式redis缓存。

集成异步消息处理中间件：Kafka是一种高吞吐量的分布式发布订阅消息系统，它可以处理消费者在网站中的所有动作流数据。 这种动作（网页浏览，搜索和其他用户的行动）是在现代网络上的许多社会功能的一个关键因素。 这些数据通常是由于吞吐量的要求而通过处理日志和日志聚合来解决。 对于像Hadoop一样的日志数据和离线分析系统，但又要求实时处理的限制，这是一个可行的解决方案。Kafka的目的是通过Hadoop的并行加载机制来统一线上和离线的消息处理，也是为了通过集群来提供实时的消息。

 

2.5.3框架亮点

• 硬件设备的高可用性。建议在整个系统中，要求所有重要设备的关键部件必须具有冗余设计。主要包括硬件设备的电源、风扇模块，存储设备的控制器、缓存模块，磁盘阵列中的磁盘镜像等。
• 系统关键服务器的高可用性。系统关键服务器采用双机设置的建设方式。在双机模式下，当一台服务器出现问题时，另一台服务器可以在极短时间内接管原服务器工作负载，保证业务不会因硬件设备故障中断。
• 数据库系统的高可用性。关键数据库系统应采用实时应用集群技术，在提升系统可用性的同时实现数据库系统的负载均衡效果。
• 系统及设备扩容能力。系统架构设计需考虑未来业务增长的潜在需求，在进行整体架构设计和关键设备选择时，一方面需要为业务发展留出一定的余量，另一方面需要所选设备和系统系统架构应具有良好的平滑扩展能力。
• 备份系统设计。系统建设过程中，必须考虑由于人为或不可抗因素而造成的系统损伤、数据丢失情况。为降低因数据丢失所造成的损失，在系统架构设计时同步考虑备份系统设计。
•  

• 2.4.2物理架构

  应用服务器间通过本地交换机互联形成应用集群，结构化和非结构化数据采用磁盘阵列存储，存储设备和应用服务器间使用高速交换机连接，通信支持10Gbit/s以太网（万兆以太网）。

  应用集群连接核心交换机、负载均衡为用户提供服务，内网用户可直接访问。外网用户或外网系统访问系统服务，必须经过防火墙认证。

  

• 1.  Cool Java 应用开发框架

• 2.5.1框架说明

  Cool Java概念：

    CoolJava是一款快速开发模块化脚手架，提供以Spring MVC为模型视图控制器和springboot两种版本，通过cooljava屏蔽数据库差异，提高系统兼容性。开箱即用，代码快速生成，使用培训成本及低。前后端分离设计，基于组件化开发方便移动端调用，复用。

  2.5.2功能说明

  系统管理功能：

    代码生成器、菜单管理、用户管理、角色管理、机构管理、文件管理、字典管理、权限管理。

• 角色管理：角色菜单权限分配，权限精确到按钮。
• 菜单管理：自定义增删改系统菜单，操作权限，按钮权限标识等。
• 字典管理：对系统中经常使用的一些较为固定的数据进行维护。
• 代码生成：CoolJava提供了功能强大的表单开发工具集，通过它，我们可以快速地开发出一个数据输入表单界面，实现表单数据的增删改查流程等基本的功能而不需要写代码，该工具能自动生成前后端源代码，我们再在源代码基础上进行简单的修改，即可实现其他的一些高级的功能。生成代码框架基于多种设计模式，屏蔽了J2ee的底层技术，程序员只需关注实际业务开发。
• Quartz调度框架：前端可视化配置定时任务。
• 可视化报表：让数据结果清晰明了的进行呈现。
• Druid连接池：开源平台上一个数据库连接池实现，它结合了C3P0、DBCP、PROXOOL等DB池的优点，同时加入了日志监控，可以很好的监控DB池连接和SQL的执行情况，可以说是针对监控而生的DB连接池，据说是目前最好的连接池。
• swagger接口API：自动生成接口文档和客户端服务端代码，方便调试。
• • 提供在线功能代码生成工具，提高开发效率及质量。
  • 封装完善的用户、角色、菜单、机构、数据字典、在线定时任务、数据报表等基础功能。
  • 集成简易报表工具，可极其方便的切换图表类型、生成报表图片。

   

• 页面校验自动生成(必须输入、邮箱校验、手机号校验等)。

• 专业接口对接机制，集成swagger-ui在线接口文档，Jwt token安全验证，方便客户端对接。

• 提供各种系统监控，实时跟踪系统运行情况。

• 支持菜单动态路由。

• 操 作权限控制精密细致，对所有管理链接都进行权限验证，可控制到按钮。

• 提供常用工具类封装，日志、缓存、验证等。

• 利用ehcache框架对经常调用的查询进行缓存，提升运行速度。

• 统一查询分页处理。

• 采用分层设计：（数据库层，数据访问层，业务逻辑层，展示层）层次清楚，低耦合，各层必须通过接口才能接入并进行参数校验，保证数据操作的安全。

• 登录用户密码进行MD5散列加密，此加密方法是不可逆的。保证密文泄露后的安全问题。

• API接口文档内容详细，极大的减少了前后端的沟通成本，同时确保代码与文档保持高度一致，极大的减少维护文档的时间。

 

2.5.4技术框架

后端技术框架：

核心框架：Spring Framework 4.1

视图框架：Spring MVC 4.1

持久层框架：Mybatis 3.1.1

安全框架：Apache Shiro 1.3.2

数据库连接池：Alibaba Druid 1.0

接口测试框架：Swagger2

项目构建管理：Maven

日志管理：SLF4J 1.7.7、Log4j 1.2.17

定时框架：Quartz 2.0.1

模板引擎：Freemarker 2.3.1

其他：JUnit4、Kafka、Zookeeper、Dubbo、Jackson 、Ehcache

前端技术框架：

JS框架：jQuery

前端页面框架：Layui

富文本编辑器：UEditor

树结构控件：jQuery zTree

技术实现

 

CoolJava平台作为信息系统规划中“云+网+端”、“微服务”、“自主可控”、“技术先进”的整体要求，以 Java 为核心开发语言，遵守 J2EE 开发标准，以 Spring Boot + Srping Cloud 为主的微服务技术框架，结合 Activiti 作为流程引擎。

 

3.1图形化元数据管理

     图形化的操作为用户提供快速、方便、简洁的自主业务维护途径，避免了传统系统通过代码修改、版本发布应对业务变更的落后方式。节省了版本开发、系统测试时间，使得用户可以专注于业务需求，从技术上保证了用户可以快速响应业务变更，提升了用户工作效率。

元数据，作为描述数据的数据，数据模型使得主数据具备了较高的扩展能力， 可根据业务的发展需要增加新的元数据类型或更新现有数据模型，以应对新的业务需求；流程定义，可以让用户方便、快捷的调整业务审批流程、审批权限。

图形化的元数据管理，使得用户更加方便的调整业务。

模型管理

    模型管理主要包含数据建模。当业务发展，需要新增某类型的数据时，用户可根据业务需要，在系统自行维护，无需系统版本更新，其具体流程为：

数据建模→流程审批→模型发布→数据维护

其中数据建模，用户通过系统页面直接进行主数据模型构建模型属性可动态添加，并可对数据类型、数据长度、数据精度、编码规则、是否为空、默认值等属性进行配置。

流程引擎

   流程管理，采用业内先进的 Activiti 流程引擎，并采用微服务设计思想，流程系统可独立部署，为CoolJava平台提供通用的流程服务，流程数据与业务数据完全解耦，所有流程在流程中心数据库进行统一管理、统一监控。

菜单管理

平台提供了功能菜单的可视化管理功能，可动态对系统菜单进行配置，可定义菜单显示名称、路径、增加功能权限控制等功能。

菜单可以针对角色、用户组、用户等分别进行独立授权。

 

1. HTML5 应用平台

 

 

 

系统平台前端显示层基于 HTML5 标准开发，主要包含表单设计器、表单解析引擎、脚本解析引擎、事件驱动机制、RPC 通信、对象传输序列化机制、表单响应式显示等功能，支持 IE、Edge、Chrome、FireFox、Safari 等主流浏览器。

HTML5 平台的核心技术主要包括：将表单定义为统一的为标准 JSON 格式， 使其可跨平台解析表单设计器设计的表单（解析成 HTML5 表单界面）；动态执行 JavasSript 的脚本引擎，根据表单上下文，动态执行脚本；HTML5 客户端与服务器端的 RPC 通信机制；HTML5 客户端与服务器端数据对象的映射及序列化和反序列化数据的传输机制；事件驱动模型的处理，通过增、删、改等事件保证数据的一致性；HTML5 组件布局根据设备分辨率按百分比显示的问题。

 

 

 

 

3.3移动应用平台

 

采用了 React+HTML5 轻应用与原生开发相结合的技术路线，具有快速可视化开发、 快速交付、易于集成的特点，满足企业移动制单、移动审批、移动报表展示等所有移动办公业务场景需求。

功能介绍

移动应用开发平台提供可视化开发表单设计器，通过可视化开发方式设计移动业务表单，生成 HTML5 或原生业务表单。设计器提供列表、日历、布局、报表等多种业务组件，可快速定制可视化界面。

技术架构

移动开发平台集成了多引擎开发技术、基于 Android 系统的碎片化保活技术、分布式内存数据库性能优化技术、分布式消息服务技术、基于微服务的多业务集成技术以及流媒体服务适配技术等，采用 SOA 架构设计，建立了移动端快速开发的应用平台，实现数据、业务等信息融合，构建覆盖多业务领域的移动端应用。其技术架构如下图：

 

 

框架（Mobile FrameWork）

数据层是移动开发平台的基础。主要包括远程服务调用、数据对象管理、消息服务、组件管理、视图管理、设备管理等。

 

组件是平台的中间层，是定制化组件工具的核心部分，提供先进的配置化、可复用的组件。组件主要包括业务组件、分析组件、模型组件、样式组件、适配器组件、Action 组件、以及存储消息组件等。

 

 

应用层是业务逻辑层，是针对不同业务需求目标研发并实现的功能模块。基于模型设计器、服务编排设计器、流程设计器和表单设计器中实现具体业务逻辑， 完成业务功能。

移动开发平台分为操作系统层、开源库、核心层、应用层几大部分。其中，

操作系统目前支持 IOS、Andriod 两个平台。

        应用层负责解析服务端发来的各类单据，实现良好的展示。单据可能包含多条明细，或包含附件文件，应用层都可以支持下载查看。

3.4技术实现原理

平台采用了多引擎开发技术路线，集成了 HTML5 和 React Native 开发引擎，集多种开发方式优点于一体,设计统一的调用规范与封装方式，实现统一集成开发，使各技术开发的组件在移动应用平台中风格一致，解决基于 Android、iOS 移动平台各种开发技术只能独立开发移动应用，无法统一开发移动应用的问题，实现移动平台多种语言共同开发的效果。

 

 

• 组件（Mobile Component）
• 应用

 

 

（1）HTML5 开发引擎

移动应用开发平台充分利用 Android 端 WebView 的特性，对其属性与协议方法进行管理控制，充分利用 WebView 的高度定制性，完成 Android 端WebBrowser 组件的封装，实现Android 端使用WebBrowser 组件加载HTML5 界面时，内存占用量小，快速、稳定。移动应用开发平台实现了在线或离线 HTML5 网页的统一加载，减少 HTML5 网页的缓存文件，提高加载 HTML5 网页的稳定性。

移动应用开发平台通过HTML5 开发引擎对Android 和iOS 统一开发规范。统一 HTML5 网页离线路径，统一放置到资源文件下的 html 文件中，方便对离线网页的管理。通过统一的加载接口便捷、高效的加载离线 HTML5 网页，加快开发速度与降低开发难度。平台通过定义 WebBrowser 规范，实现统一的原生加载 HTML5 网页的按需加载规则，实现 HTML5 引擎对 HTML5 网页的按需加载，不加载多余内容，使原生加载 HTML5 网页更流畅，降低加载 HTML5 网页导致的内存消耗，解决传统方式加载 HTML5 时内存泄露的问题，使用户对加载HTML5 时的体验更友好。

 

（2）ReactNative 开发引擎

移动开发平台集成 React Native 运行时环境，定义 React Native 与原生

（Android、iOS）交互规范，优化 RCTBridge，基于 RCTBridge 开发 317 个原生功能接口，如调用原生文件系统、获取 GPS 信息、原生摄像头接口、原生相册接口、原生通讯录接口数据库接口等，解决无法调用底层定位、相册、通讯录等接口的难题，统一 Android 和iOS 对React Native 的调用接口，解决 React Native 原生功能较少问题。通过将 React Native 的 JS 文件与图片资源，放入应用本地存储（iOS 为沙盒、Android 为资源文件下），实现离线加载。在 React Native 部分需求发生变化时，只需更新下载应用资源文件，无需升级 APP 就能达到程序的更新，并实现 React Native 代码热更新功能，解决代码动态更新的难题。对 ReactNative 进行组件化处理，由 ReactNative 引擎进行统一管理， 实现对组件生命周期的控制，平台对 ReactNative 界面的加载速度较传统ReactNative 加载方式提高 20%。

3.5多语言支持

针对多语言提供了完整的解决方案，主要包括对资源文件、主应用界面、功能菜单、后台服务、主数据等模块的多语言支持。

1. 资源文件多语言

系统登录界面和首界面具有语言选择功能，当选择了不同的语言后，系统可以根据当前语言类型切换显示对应的背景图片、标题图片等资源文件，平台提供资源文件配置功能，用户通过简单的配置就可以实现对资源文件的多语言配置。

1. 应用界面多语言

前端应用界面的语言文字需要根据本地环境或选择的语言进行显示，平台支持通过增加 properties 多语言配置文件的方式扩展多语言的支持。

1. 功能菜单多语言

系统功能菜单是通过 XML 文件的形式定义的，可以根据语言种类定义多种类型的功能菜单 XML 文件，菜单文件名以语言类型为后缀，功能菜单显示时会根据语言类型加载对应的菜单配置文件，实现功能菜单的多语言显示。

1. 后台服务多语言

平台提供后台服务的多语言开发规范，按照开发规范开发的后台服务插件，支持多语言的灵活扩展，某些场景下，后台服务需要给客户端返回友好的提示信息，符合开发规范的后台服务会根据前端语言类型返回对应的多语言提示信息。

1. 多语言

针对需要提供多语言支持，平台提供了创建多语言表的功能，多语言表记录需要多语言处理的列数据，主数据加载时，系统会根据语言类型加载对应的多语言类数据。

此外，平台还提供了多时区、多币种的支持，具体的业务功能可以灵活配置启用。

3.6云管理平台

通过云管理平台，以集中统一方式管理物理机、虚拟化平台、以及运行在其上的应用群，能够在不影响系统应用正常运行的情况下，快捷的实现应用的动态拆分、整合、迁移、部署、下线、数据同步、资源调度、弹性扩展等操作。

3.6.1系统功能

基于微服务架构和 Docker 容器技术的云平台提供一套服务快速开发、部署、运维管理、持续开发、持续集成的流程。平台提供基础设施、中间件、数据服务、云服务器等资源，开发人员只需要关注业务代码并提交至平台代码库，完成必要的配置，系统会自动构建、部署，实现应用的敏捷开发、快速迭代。在系统架构上，云平台主要分为微服务架构、Docker 容器技术、云资源管理、DveOps 四部分。

微服务访问大致路径为：外部请求 → 负载均衡 → 服务网关（GateWay）

→ 微服务 → 数据服务/消息服务。服务网关和微服务都会用到服务注册和发现来调用依赖的其他服务，各服务集群都能通过配置中心服务来获得配置信息。

基于 Spring Cloud 的微服务思想架构设计，把一个大型的单个应用程序和服务拆分为数个微服务，每个服务以独立的方式在轻量级容器中运行，同时提供标准统一的 REST 调用接口，以 JSON 的方式传输数据，它可以做到每种服务可单独进行开发与运维互不影响，轻量级容器可以自动快速分布式布署。

 

1. 架构设计

 

由于系统的每个服务都比较简单，只专注于一个特定的功能，占用资源少、运行效率高；微服务架构保证了系统的松耦合，可使用持续集成工具进行灵活的自动集成部署；微服务间通过 Restful 标准接口通讯，易于扩展，提高了系统扩展及集成的灵活性，可充分使用云平台统一管理微服务，降低运维难度。

采用服务组合的方式来构建一个应用，服务独立部署在不同的容器中，不同服务通过一些轻量级交互机制 HTTP Resource API 来通信，服务可独立开发、独立运维、独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，但是都需要遵守明确的标准技术规范。

4.1架构特征

1. 原子服务: “高内聚，松耦合”，  服务被设计为功能相对独立，尽量不依赖其他服务的独立功能提供者;微自治：服务足够小，功能单一，可以独立打包、部署、升级、回滚和弹性伸缩，不依赖其他服务，实现局部自治；
2. 服务是可组合、可编排的：多个服务可能被编排组合成一个新的服务，这允许不同逻辑抽象的自由组合，促进服务的复用, 以面向微服务编排的理念为上层业务快速定制应用；
3. 易维护：微服务应用侧重于应用的实时监控，每个单独的服务设置精密的监控和记录，这些服务包括在 dashboard 上显示服务启用/宕机状态，以及各种相关的运营和业务指标，一旦出现异常能精准定位，触发跟进和调查；
4. 高恢复能力：因为每个服务是独立的，与其他服务是完全解耦的，独立的运行可以立即提供与其他组件中的故障独立的恢复能力。

 

4.2架构优势

1. 每一个微服务只专注于一个特定的功能，占用资源少、运行效率高。
2. 由于每一个微服务只专注一个特定的功能,与其他系统功能完全解耦, 这种架构使得每个服务都可以有专门开发团队来开发。开发者可以自由选择开发技术，提供 API 服务。
3. 微服务架构模式使得每个微服务可以进行独立部署、运维，开发者不再需要协调其它的资源来配合本次服务的部署。
4. 微服务架构模式使得每个服务独立扩展。你可以根据每个服务的规模来进行合理的资源分配，比如流程中心压力比较大，可以单独给流程中心微服务单独增加资源。
5. 微服务架构可弹性扩展资源，这样便能在无运维人员介入的情况下实现自动调整计算资源，当访问量上涨时增加计算能力，而当访问量下降时减小计算能力，既保障了系统的稳定性与高可用性，又节约了计算资源成本。
6. 微服务运行在 docker 容器中，Docker 容器几乎可以在任意的平台上运行，所以微服务具有很高的移植性，可以快速在移植到物理机、虚拟机、公有云、私有云等异构平台中，并以接近实时的速度实现负载的动态管理，快速扩容应用和服务。
7. 微服务间通过 Restful 标准接口进行通讯，易于扩展，提高了系统扩展及集成的灵活性。

   4.3云资源管理

    

   4.3.1主要功能

    

   云管理平台对于同构异构分散多地的云资源通过 kubernetes、Docker 等技术对集群集中统一管理、任务统一调度、容器统一管理，确保各类资源随着应用的需求动态调度，同时简化应用程序的开发、部署难度，实时的采集系统运行过程中的日志信息。云管理平台主要包括如下四部分：

   为整个数据中心提供分布式调度与协调功能，统一协调各类资源，实现数据中心级的弹性伸缩能力。实现高可用性、容灾，云平台所有组件采用分布式架构， 应用跨机房分布式调度。自动为宕机服务器上运行的节点重新分配资源并调度， 保障业务不掉线，做到故障自愈。

   对于基础架构和应用编排问题，云管理平台提供一系列自动编排工具，能够实现应用部署的整个过程的自动化，满足了开发测试过程中快速创建开发测试环境需求和运维中一键快速扩容缩容、自动故障恢复等场景的自动化需求。

   对于环境创建准备慢的问题，云管理平台提供了以容器为基础封装各类应用和运行环境，实现资源的高效利用率，数据中心操作系统相较于虚拟机有着基于CPU、内存的更细粒度的资源调度，多个计算框架或应用程序可共享资源和数据， 提高了资源利用率。

   提供云管理平台的门户。对云框架层各个组件产生的日志，通过聚合、缓存、流式处理。为节点提供组件的包管理，为集群提供包管理。提供身份认证和权限管理。

   4.3.2技术路线

    

8. 集群管理资源整合，提高资源利用率。通过 kubernetes 分布式系统来管理资源和任务，统一调度管理分布式集群的计算资源、网络资源、存储资源， 将物理资源整合成“巨型计算机”；通过 kubernetes 将“小云“整合成”大云”。
9. 调度管理，调用 kubernetes 创建运行的任务 Job，并且对任务进行启动、停止等管理。
10. 容器化，通过 Docker 将应用容器化。通过 Docker 实现以容器为基础封装各类应用和运行环境，实现应用的快速发布。
11. 跨平台，通过容器镜像（Docker Registry）仓库，实现应用的跨平台部署和运行。
12. 容错与扩展， 更高效的管理系统， 支持应用的横向扩展；通过对 kubernetes 的任务进行统一的调度管理，实现服务的长时间运行及对服务运行状态的监控，同时实现服务的扩缩容，如果一台服务器发生故障， 它的工作负载可以自动迁移到别的地方。
13. 对于云平台产生的日志，通过 Fluentd 采集，发送到 ElasticSearch 创建索引，对日志进行统一的管理分析。通过 kibana 构建图形化界面查看日志。

14. 4.4系统技术架构

    系统主要包括四层：

15. 基础组件，主要包括日志及监控模块，组件的日志信息、日志的聚合、组件监控；网络模块，四层虚拟 IP 的管理、端口映射服务；以及安装systemd服务单元，为每个主机建立指定角色。
16. 平台框架，包括集群的管理，服务的编排，安全管理，以及容器的运行时环境。
17. 应用容器化层，通过 Docker 技术以应用为单元进行“集装封箱”。
18. 门户，包括服务管理、节点管理、网路管理、安全管理、系统设置等。

19.  

    4.4.1服务网关（GateWay）

    外部请求经过ELB 负载均衡后路由到GateWay 集群中的某个GateWay 服务，由 GateWay 服务转发到微服务。API 网关服务主要有以下基本能力：

    动态路由：动态的将请求路由到所需要的后端服务集群。虽然内部是复杂的分布式微服务网状结构，但是外部系统从网关看就像是一个整体服务，网关屏蔽了后端服务的复杂性。

    限流和容错：为每种类型的请求分配容量，当请求数量超过阀值时抛掉外部请求，限制流量，保护后台服务不被大流量冲垮；党内部服务出现故障时直接在边界创建一些响应，集中做容错处理，而不是将请求转发到内部集群，保证用户良好的体验。

    身份认证和安全性控制：对每个外部请求进行用户认证，拒绝没有通过认证的请求，还能通过访问模式分析，实现反爬虫功能。

    监控：网关可以收集有意义的数据和统计，为后台服务优化提供数据支持。访问日志：网关可以收集访问日志信息，比如访问的是哪个服务？处理过程

    （出现什么异常）和结果？花费多少时间？通过分析日志内容，对后台系统做进一步优化。

    4.4.2服务注册与发现

    通过 Spring Cloud 体系中的 Eureka 组件提供了服务注册与发现机制，服务的提供方要注册报告服务地址，服务调用方要能发现目标服务。微服务架构中使用了 Eureka 组件来实现服务的注册与发现。所有的微服务（通过配置 Eureka 服务信息）到 Eureka 服务器中进行注册，并定时发送心跳进行健康检查，Eureka默认配置是 30 秒发送一次心跳，表明服务仍然处于存活状态，发送心跳的时间间隔可以通过 Eureka 的配置参数自行配置，Eureka 服务器在接收到服务实例的最后一次心跳后，需要等待 90 秒（默认配置 90 秒，可以通过配置参数进行修改）后，才认定服务已经死亡（即连续 3 次没有接收到心跳），在 Eureka 自我保护模式关闭的情况下会清除该服务的注册信息。所谓的自我保护模式是指， 出现网络分区、Eureka 在短时间内丢失过多的服务时，会进入自我保护模式， 即一个服务长时间没有发送心跳，Eureka 也不会将其删除。自我保护模式默认为开启，可以通过配置参数将其设置为关闭状态。

    Eureka 服务以集群的方式部署，集群内的所有 Eureka 节点会定时自动同步微服务的注册信息，这样就能保证所有的 Eureka 服务注册信息保持一致。那么在 Eureka 集群里，Eureka 节点是如何发现其他节点的呢？我们通过 DNS 服务器来建立所有 Eureka 节点的关联，在部署 Eureka 集群之外还需要搭建 DNS 服务器。

    当网关服务转发外部请求或者是后台微服务之间相互调用时，会去 Eureka 服务器上查找目标服务的注册信息，发现目标服务并进行调用，这样就形成了服务注册与发现的整个流程。

    4.4.3微服务部署

    微服务以镜像的形式，运行在 Docker 容器中。Docker 容器技术让我们的服务部署变得简单、高效。传统的部署方式，需要在每台服务器上安装运行环境， 如果我们的服务器数量庞大，在每台服务器上安装运行环境将是一项无比繁重的工作，一旦运行环境发生改变，就不得不重新安装，这简直是灾难性的。而使用Docker 容器技术，我们只需要将所需的基础镜像（jdk 等）和微服务生成一个新的镜像，将这个最终的镜像部署在 Docker 容器中运行，这种方式简单、高效， 能够快速部署服务。每个 Docker 容器中可以运行多个微服务，Docker 容器以集群的方式部署，使用 Docker 云资源管理平台对这些容器进行管理。我们创建一个镜像仓库用来存放所有的基础镜像以及生成的最终交付镜像，在镜像仓库中对所有镜像进行管理。

    4.4.4服务容错

    使用 Spring Cloud 微服务架构中 Hystrix 组件来进行容错处理。Hystrix 是 Netflix 的一款开源组件，它通过熔断模式、隔离模式、回退（fallback）和限流等机制对服务进行弹性容错保护，保证系统的稳定性。

    熔断模式：熔断模式原理类似于电路熔断器，当电路发生短路时，熔断器熔断，保护电路避免遭受灾难性损失。当服务异常或者大量延时，满足熔断条件时服务调用方会主动启动熔断，执行 fallback 逻辑直接返回，不会继续调用服务进一步拖垮系统。熔断器默认配置服务调用错误率阀值为 50%，超过阀值将自动启动熔断模式。服务隔离一段时间以后，熔断器会进入半熔断状态，即允许少量请求进行尝试，如果仍然调用失败，则回到熔断状态，如果调用成功，则关闭熔断模式。

    隔离模式：Hystrix 默认采用线程隔离，不同的服务使用不同的线程池，彼此之间不受影响，当一个服务出现故障耗尽它的线程池资源，其他的服务正常运行不受影响，达到隔离的效果。例如我们通过 andThreadPoolKey 配置某个服务使用命名为 TestThreadPool 的线程池，实现与其他命名的线程池隔离。

    回退（fallback）：fallback 机制其实是一种服务故障时的容错方式，原理类似 Java 中的异常处理。只需要继承 HystixCommand 并重写 getFallBack()方法，在此方法中编写处理逻辑，比如可以直接抛异常（快速失败），可以返回空值或缺省值，也可以返回备份数据等。当服务调用出现异常时，会转向执行getFallBack()。有以下几种情况会触发 fallback：

    （ 1 ） 程 序 抛 出 非 HystrixBadRequestExcepption 异 常 ， 当 抛 出HystrixBadRequestExcepption 异常时，调用程序可以捕获异常，没有触发fallback，当抛出其他异常时，会触发 fallback；

20. 程序运行超时；
21. 熔断启动；
22. 线程池已满。

23. 限流： 限流是指对服务的并发访问量进行限制，设置单位时间内的并发数，超出限制的请求拒绝并 fallback，防止后台服务被冲垮。

    Hystix 使用命令模式： HystrixCommand 包装依赖调用逻辑，这样相关的调用 就 自 动 处 于 Hystrix 的 弹 性 容 错 保 护 之 下 。 调 用 程 序 需 要 继 承HystrixCommand 并将调用逻辑写在 run()中，使用 execute()（同步阻塞）或queue()（异步非阻塞）来触发执行 run()。

    4.4.5动态配置中心

    配置中心提供了集中式配置管理功能，基于 docker 部署模式的微服务启动时，根据服务类型及运行环境标志，动态的从配置中心获取对应配置，同时监听配置中心配置修改操作。配置中心提供 UI 管理功能，系统管理员可以在配置中心管理界面修改微服务配置，配置发布后，会实时将配置文件推送给相应的微服务应用，实现微服务的动态配置。

    4.4.6微服务追踪

    微服务追踪机制，通过微服务追踪日志可快速定位问题、故障节点、分析调用耗时等。目前支持 Sleuth+Zipkin 等服务追踪框架。

    4.4.7日志中心

    日志集中存储处理方案，以提升日志管理规模和管理效率。可分布式管理各微服务应用日志，快速定位日志内容。

    4.4.8灰度发布

    提供灰度发布配置机制，支持基于 Docker 容器化微服务部署架构下的灰度发布机制。

    灰度发布系统可以部分用户或单位优先使用新版本系统，另一部分用户仍然使用历史稳定版本，当新版本系统出现故障，这部分用户或单位可快速切换至历史稳定版本，降低风险影响范围，如系统正常运行，可扩大用户使用范围；

    灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，实现程序有序和自动化升级。

    4.5高并发与高性能处理

    平台基于微服务架构思想设计，采用容器化的分布式部署模式，在系统接入层、应用服务层、数据存储层均采用分布式负载，同时采用消息机制实现异步通信提高系统并发，并且增加限流保护与熔断机制确保系统的稳定性，保证了高并发处理能力。利用缓存数据库、MQ、并行计算、前端缓存等技术保证了系统的高性能。

    4.5.1高并发处理

    系统的接入端采用负载均衡策略，有效分散、平衡用户的请求，提高系统接入层的并发能力；通过 Docker、kubernetes 等实现根据各微服务的资源（CPU、内存和 TPS 等）使用情况对运行容器进行弹性伸缩，保障应用层的系统并发能力；系统间调用采用 MQ 实现消息通信的异步化处理，达到高并发情况下流量消峰的目的；采用 Redis 等缓存技术，将系统中使用频率高、相对静态的数据进行缓存，避免每次使用数据时访问数据库，数据缓存有效保障了系统并发能力； 数据库采用分布式集群部署、分库、分表、读写分离等多种方式，提高数据库并发处理能力。

    通过以上措施，确保系统对高并发的要求，满足系统并发用户的数量要求， 同时根据用户的增加能够随时进行资源动态扩展进一步提高系统并发。

     

    4.5.2高性能保障

    系统的接入端采用负载均衡策略，针对每项服务分别搭建的集群环境，可有效分散、平衡用户的请求，确保接入层每个请求的快速响应；采用 MQ 实现消息通信的异步化处理，避免系统间调用的相互等待，降低系统间的耦合度，保障前端用户反馈的响应速度；采用 Redis 等缓存技术，将使用频率高、相对静态的数据进行缓存，避免每次使用数据时访问数据库，从而提高系统的处理效率，缩短每次访问系统的占用时间；针对数据需要实时处理且并发量高的情况下，通过采用 Storm 技术，搭建 Storm 集群服务，实现数据的实时处理，通过使用利用流式计划数据处理计算实现查询数据的事前准备，确保用户查询时的响应速度； 充分利用 HTML5 的客户端 indexDB 数据库，实现表单、元数据、关键指标等数据的预加载和缓存。此外，客户端采用虚拟 DOM、服务器端渲染等多项技术保证了前端的渲染效率，提高页面的相应时间。

24. 集成方案

25. 5.1集成架构设计

    CoolJava技术方案与他系统间集成方式主要通过 ESB 进行集成，数据量大的情况下通过 ETL 方式进行集成，比如：主数据导入、与 BI 报表系统间的集成。CoolJava平台与其他系统间集成必须遵循统一的数据集成标准和规范。

    5.2平台集成能力

    平台基于微服务架构，提供的接口符合标准的 REST 规范，数据使用 JSON 格式传输，可与其他系统无缝集成。平台提供企业服务总线 ESB，具有灵活的集成接口定制功能，日志采用异步方式存储于 ElasticSearch 中，有效的保证了系统集成性能。此外，平台还支持应用服务注册与发现、MQ 异步消息通信等多种方式与其它系统进行集成。

    5.3核心服务组件

    组件总体概述

26. 组件设计思路

27. 核心服务组件设计包括以下内容：

28. 系统对外提供相关的实时访问接口，具体接口规范参考“接口技术规范”文档内容。
29. 提供直接可用的粗粒度的、细粒度的的服务。不仅包括业务逻辑简单、无须事务支持的服务，还应包括要求事务支持、逻辑复杂的服务。服务除了包含基本的 CRUD 操作外，还提供的锁定/解锁、合并、疑似查询、编码分配等服务。同时还支持对原子服务进行封装并组合成新的、复杂的服务。
30. 满足相应的校验规则要求，其中数据格式校验主要通过接口报文约束实现，其他的业务逻辑校验在服务里面实现。
31. 对于业务数据的新增操作，必须满足相应的唯一识别要求。
32. 对于业务数据的修改操作，必须满足相应的覆盖原则要求。
33. 对于疑似查询疑似发现操作，必须满足相应的疑似发现原则要求。
34. 编码分配服务，满足预定义的编码规则，编码规则由数据标准管理里
35. 面的编码管理功能模块进行维护，具体参考数据标准管理相关章节。
36. 保存的历史数据，对核心数据，都需要保留数据新增、修改、删除、锁定、解锁的历史。
37. 需要记录所有的操作日志以及异常出错的情况，以便后续跟踪。
38. 提供相关的管理功能，如批量处理管理、日志管理等

39.  

40. 组件服务框架概述

41. 服务框架采用分层的设计思想，在不同的层提供对应的功能模块，做到层级的隔离和解耦，同时可以提高复用性。服务框架分层模型划分为如下三层： WebService 接入层，系统基础组件层，组合服务提供层。

     (—）WebSerice 接入层

42. 提供 WebService 的 SOAP 报文方式接入；
43. 请求报文和应答报文的完整日志记录；
44. 生成流水号，用来标准这次请求的相关操作；
45. 报文解析，负责把 SOAP 报文转换为对象结构；
46. 身份认证，根据报文中传递过来的身份信息，可以进一步做身份认证；
47. 异常控制，当接入层或者后面的服务调用出现异常后，可以做异常统一捕获与控制，返回更友好的信息给调用方。

48.  (二）系统基础组件层

49. 提供统一的访问组件，JMS 访问组件，JDBC  数据库访问组件，日志模块，系统参数模块。组合服务提供层
50. 组合服务提供层：其中又分核心服务提供模块，内部组合服务模块， 业务公共组件模块；
51. 核心服务包含对外暴露的七大服务，提供对外调用的接口，复合对象的拆分和组装等；
52. 内部组合服务模块，提供复合对象父对象的服务封装；
53. 业务公共组件模块，提供数据校验，数据清洗，数据版本识别组件。

54.  

    5.4发布订阅组件

    发布订阅机制介绍

55. 异步服务请求

56.  

    基于异步的服务请求经由 ESB 的处理过程，以下是详细的步骤说明：

57. 服务请求方发起服务调用请求，并同步等待一个通讯应答；
58. ESB 接收到服务请求方的服务调用请求后，立即同步返回给服务请求方一个通讯应答；
59. ESB 同时调用服务提供方的服务，并同步等待调用结果；
60. 服务提供方将处理结果同步返回给 ESB；
61. ESB 通过服务请求方提供的回调服务，异步将处理结果返回服务请求方；
62. 服务请求方收到处理结果后，同步返回给 ESB 一个通讯应答。
63. 同步服务请求

64. 基于同步的服务请求经由 ESB 的处理过程，以下是详细的步骤说明：

65. CoolJava技术方案请求调用 ESB，并将相关请求数据发送给 ESB；
    1. ESB 接收到调用请求后，调用CoolJava技术方案服务接口，将相关参数发送给CoolJava技术方案；
    2. CoolJava技术方案接收到调用请求后，进行业务相关处理，同步返回响应信息；
    3. ESB 将响应结果同步返回给CoolJava技术方案。

66.  

67. 架构设计说明

68.  

    逻辑架构主要包括以下几个部分：

69. 发布适配器

70. 发布适配主要负责接收 SOAP/HTTP 请求，ESB 将通过发布适配器对外提供发布订阅模式的 Web 服务。

71. 发布订阅引擎

72. 发布订阅引擎从队列中读取消息，并对其进行 Pub 处理，Pub 处理完成后对前端适配器发送处理响应报文。

73. 订阅适配器

74. 订阅适配器主要实现 ESB 与订阅方系统之间的报文/协议转换。

    5.5门户系统集成方案

    基于微服务架构研发，对外提供 REST 接口服务，以 JSON 数据格式进行交互，应用基于 B/S 架构部署，可通过 https 协议访问，前端页面采用 HTML5 技术开发，支持 IE、Chrome、Firefox、Safari 等主流浏览器，支持统一用户集成、统一认证集成、统一待办集成、移动集成、统一UI 规范，可与门户系统无缝集成。

    5.5.1统一用户集成

    提供统一用户集成方案，可通过配置的方式启用用户中心基础数据同步功能。平台提供了用户中心查询数据与系统组织基础数据表的映射配置功能，系统根据配置调用用户中心提供的 REST 服务接口，查询组织机构、部门、人员、用户等基础数据，根据数据配置映射关系将数据转换本地数据并插入业务系统数据库，平台本地数据编号和用户中心数据编号保持一致，保证了数据增、删、改的同步。此外，平台通过权限控制，只允许添加运维所需的私有账号，其他所有用户账号与用户中心保持同步。

    

    用户同步方式提供了定时同步和手动同步两种解决方案：

     

75. 定时同步

76. 根据统一用户管理系统提供的 Rest 接口及参数要求开发用户信息同步插件， 平台提供定时任务配置功能，可根据需求配置定时任务执行时间间隔，系统自动增量同步用户管理系统基础数据信息。

77. 手动同步

78. 平台提供手动同步基础数据功能，用户可以通过手动点击用户同步按钮，触发数据同步操作，完成当前业务系统的基础数据更新。

     

    5.5.2统一认证集成

    自身支持 SSO 单点登录系统，通过配置就可以启用统一认证。此外，平台登录验证模块提供可扩展验证机制，可以任意扩展登录验证方式，可以轻易集成其他统一认证系统，当用户第一次访问应用系统的时候，由于还没有登录，平台通过认证校验过滤器将请求重定向到认证系统中进行登录，根据用户提供的登录信息，认证系统进行身份效验，如果通过效验，返回给用户一个认证的凭据

    

    （ticket），用户再访问别的应用的时候就会将这个凭据带上，作为自己认证的凭据，应用系统接受到请求之后会把凭据送到认证系统进行校验，检查凭据的合法性，如果通过校验，用户就可以在不用再次登录的情况下访问其它应用系
    5.5.3流程任务集成。

     工作流引擎在节点产生任务时，会派发任务生成事件，具有高可扩展性，通过监听业务流程节点产生的事件，获取生成的待办任务信息，通过异步的方式调用 Rest 或 Web Service 接口，将待办任务信息传送至企业门户，同时记录任务的传送状态，如果传送失败，系统利用定时重传机制重新传送待办任务信息，增强任务传递的及时性和完整性，重传超过 3 次，则发送传送失败消息通知系统管理人员。用户通过企业门户打开待办时，调用待办任务的处理界面进行处理，处理完成后，根据用户的处理情况将待办完结信息发送到企业门户，已完结任务信息在企业门户不再显示。

    推送待办任务到门户统一待办库之后，触发门户系统的消息发送机制，给相关用户发送短信、邮件等提醒信息。

    
     

    5.5.4消息集成

    平台系统提供了消息中心集成模块，可以通过配置的方式启用消息中心集成

    服务，系统可以根据业务需求调用消息集成模块发送消息通知。发送消息通知的消息通道是可配置的，用户可以根据具体业务需求，选择门户通知消息，移动门户消息、短信、邮件中的一个或多个消息通道，发送给相关的人员。此外，系统具有自定义消息模板的功能，用户可以根据业务场景自定义消息模板，提供个性化的消息内容格式。

    

     

    5.6集成技术规范

    5.6.1数据传输规范

    任何与CoolJava平台进行集成必须通过 ESB 进行，系统集成双方需在 ESB 注册各自服务接口

    数据传送以标准的 XML 报文进行，报文 Header 中需包含请求系统、用户名和密码等信息，业务报文内容需要进行统一进行加密，集成双方系统必须遵循CoolJava平台制定的数据集成规范。

    5.6.2统一 UI 规范

    CoolJava系统平台给的 PC 端和移动端显示界面均采用 HTML5+CSS 技术开发, 前端可视组件的开发全部基于皮肤分离的原则原则，将业务逻辑组件与皮肤样式分离，实现了完全隔离，在不影响业务逻辑的基础上，可根据 UI 规范，使用 CSS3 快速定义显示风格，实现皮肤的动态切换。

     

79. 软件技术说明

80. 6.1操作系统

    推荐系统：CentOS 7.4 x64

    6.2数据库

    分类	软件名称	收费情况	备注
    关系数据库	MySQL 5.7+	免费
    缓存数据库	Redis 4.0+	开源免费

     

     6.3其他支撑软件

       

    分类	软件名称	收费情况	备注
    云平台管理	docker-ce 18.03	开源免费
    	DockerRegister	开源免费
    	kubernetes 1.10+	开源免费
    	Spring boot 2.0+	开源免费
    	Nginx1.10+	免费	动态反向代理
    	Eureka 1.9.0+	免费	服务注册发现
    	Spring cloud Finchley.SR1	开源免费
    大数据	Apache Spark or Hadoop
    JVM	OpenJDK1.8+	开源免费
    应用容器	Tomcat 8.5+	开源免费
    消息队列	RabbitMQ	开源免费
    	kafka	开源免费
    服务器监控	Promethues 2.0+

     

    6.4系统扩展性

     

    依托CoolJava平台先进的分布式技术架构与灵活快速的开发平台，可以满足现有业务场景与技术要求。在未来有新的业务场景、新的业务品种、新的数据需求、新的数据结构、新的数据接口、新的业务流程、新的报表需求、新的模板等需求时，通过开发平台能够完成新增系统、新增功能、新增应用、新增表单、新增流程、新增接口、新增录入项、新增输出方式等过程的快速实现。在未来出现业务量增大、用户量增大、系统请求增大、数据量增大等情况时，通过分布式技术架构能够实现系统动态扩展。

    CoolJava平台的系统扩展性体现在三个方面：系统功能快速扩展、用户配置按需扩展、系统资源动态扩展。

     

    6.5系统功能快速扩展

             随着业务的快速发展，当由于新的业务需求，对CoolJava平台提出新增系统、新增功能、新增应用、新增流程、新增接口等快速扩展需求时，通过CoolJava平台能够快速实现。

81. 新增业务类型

82.  

    对于新增类型的需求通过系统提供的模型管理实现，由系统运维或开发人员将新增模型信息进行配置。定制完模型信息后，可通过CoolJava平台，使用新增模型增加新类型的数据。

83. 新增审批流程

84.  

    对于新增流程的需求通过 activiti 提供的流程管理实现，由系统运维人员将新增的流程配置到系统。系统流程配置可以根据用户需求随时进行新增业务流程的添加。

    

     

85. 新增接口

86.  

    对于新增接口的需求通过接口配置实现，由系统运维人员或开发人员将新增的接口配置完后发布到集成中心。

    6.5.1用户配置按需扩展

     

    随着业务流程的不断发展与优化，针对CoolJava平台的流程调整、界面调整、新增字段、新增数据项、新增输出格式的需求会随时出现，针对这些用户配置的调整需要，通过CoolJava平台的系统配置管理功能，能够快速按需扩展与灵活调整。

    6.5.2系统资源动态扩展

    CoolJava平台采用微服务化的分布式架构，通过 kubernetes 等实现对 Docker 化部署的应用的管理，实现根据系统资源的占用情况弹性收缩实现应用层的动态扩展。CoolJava平台数据访问通过统一的数据分布服务，根据业务要求可以灵活配置扩展数据库而无需进行功能开发，实现了数据存储层的灵活可扩展。

     

    6.6系统性能特点

    高并发：

    CoolJava平台采用分布式部署方式，在系统接入层、应用服务层、数据存储层均采用分布式负载模式，同时采用消息机制实现异步通信提高系统并发，并且增加限流保护与熔断机制确保系统的稳定性。

87. 接入层负载

88. 系统的接入端采用负载均衡策略，F5 作为负载的主接入端支持 100 万用户的同时访问，针对每项服务分别搭建的集群环境，前端通过 Ingress 作为负载接入端，每个 Ingress 接入端与 F5 的主接入端相连。采用负载均衡策略可有效分散、平衡用户的请求，提高系统接入层的并发能力。

89. 应用资源弹性伸缩

90. 通过 Docker、kubernetes 等实现根据各微服务的资源（CPU、内存和 TPS 等）使用情况对运行容器进行弹性伸缩，保障应用层的系统并发能力。

91. 利用缓存服务

92. 采用 Redis 等缓存技术，将CoolJava平台中使用频率高、相对静态的数据进行缓存，像CoolJava平台中使用的主数据、配置数据、用户基本信息、控制规则数据等进行缓存，避免每次使用数据时访问数据库，由于缓存服务采用负载架构从而保障了系统并发能力。

93. 利用异步消息服务

94. 采用 Kafaka 实现消息通信的异步化处理，达到高并发情况下流量消峰的目的。在系统间或不同系统模块间的单据状态的变化时均采用异步消息处理机制，避免系统间调用的相互等待，同时异步消息服务采用负载架构从而保障了系统并发能力。

95. 数据库负载

96. 数据库采用 RAC 方式部署提供灵活的横向扩展能力，同时提供统一的数据访问服务，支持按年度、组织架构等维度进行数据库横向分布，支持定期对数据进行归档，确保每个数据库的访问量在一定范围之内，同时确保整个系统的数据库的访问量满足并发要求。对于非结构化存储采用分布式负载部署方式，并且支持根据业务需要动态扩展，确保访问量满足并发要求。

    通过以上措施，确保系统对高并发的要求，满足CoolJava平台并发用户的数量要求，同时根据用户的增加能够随时进行资源动态扩展进一步提高系统并发。

    可追溯：

    系统所有模块与功能均通过统一的开发平台构建，发平台针对基础数据确保实现一直保存，同时提供统一的数据修改痕迹记录机制。针对元数据、主数据、流程数据、业务交易数据等数据进行变更时，详细记录变更前内容、变更后内容、变更时间、变更人等信息。

    通过统一数据访问服务，数据进行归档以后进行查询时，能够根据数据的归档情况实时调用归档数据进行查询展示。

    高性能：

    根据业务功能的应用场景，结合用户的规模、功能的使用频率、周期性影响、用户体验、响应时间要求等多方面因素，采用多种技术手段保证系统在高并发下的高性能。

97. 负载均衡

98. 系统的接入端采用负载均衡策略，F5 作为负载的主接入端支持 100 万用户的同时访问，针对每项服务分别搭建的集群环境，前端通过 Ingress 作为负载接入端，每个 Ingress 接入端与 F5 的主接入端相连。采用负载均衡策略可有效分散、平衡用户的请求，确保接入层每个请求的快速响应。

99. 缓存服务

100. 采用 Redis 等缓存技术，将CoolJava平台中使用频率高、相对静态的数据进行缓存，像CoolJava平台中使用的主数据、配置数据、用户基本信息、预算管控规则数据等进行缓存，避免每次使用数据时访问数据库，从而提高系统的处理效率，缩短每次访问系统的占用时间。

101. 应用 Storm

102. 针对数据需要实时处理且并发量高的情况下，通过采用 Storm 技术，搭建Storm 集群服务，实现数据的实时处理，通过使用利用流式计划数据处理计算实现查询数据的事前准备，确保用户查询时的响应速度。

103. 前端技术

104. 充分利用 HTML5 的客户端 indexDB 数据库，实现表单、元数据、关键指标等数据的预加载和缓存。此外，针对超过一定数据量的数据加载请求采用懒加载技术、虚拟 DOM、服务器端渲染等多项技术。

     通过负载均衡、应用分布式架构、应用云计算等多项技术，使用CoolJava平台内网与外网同时支持 2000 个并发以上，提出业务申请在 1 秒以内完成，数据查询

     在 3 秒以内完成，批量接口或指数据处理在 5 秒以内完成。

     高可用：

     CoolJava平台采用分布式部署方式，基于微服务架构方式实现，在系统接入层、应用服务层、数据存储层均采用双活机制，同时对服务间的调用增加熔断机制， 达到设定阀值时对服务功能进行降级处理，避免系统出现雪崩，实现系统的高可用。

105. 集群部署

106. CoolJava平台的各模块均采用 Kubernetes+Docker 方式发布，每一项功能服务采用集群方式部署，每项集群服务通过 Ingress 作负载均衡。

107. 故障隔离

108. 根据部署的多个集群服务，每个集群服务都以 Ingress 作负载，同时配置Keepalived 功能，实现对故障节点的实时监测与故障隔离，从而保证不间断提供服务。

109. 过载保护

110. 系统根据具体的业务场景，对于服务间的调用可能存在大并发情况下，增加过载保护机制，当系统检测到系统的资源相关指标到达设定的阀值时，新发起的服务请求直接返回，从而保护系统服务不至于过载而停止响应；同时当系统检测到资源降下来后，自动关闭过载保护机制。

111. Mysql数据库采用MHA高可用方案

112.        MHA（Master High Availability）是一套优秀的作为MySQL高可用性环境下故障切换和主从提升的高可用软件。在MySQL故障切换过程中，MHA能做到在0~30秒之内自动完成数据库的故障切换操作，并且在进行故障切换的过程中，MHA能在最大程度上保证数据的一致性，以达到真正意义上的高可用。

     

113. oracle数据库采用 RAC

114. 所有CoolJava系统平台数据均保存在数据库中，为了避免数据库出现单点故障， Oracle采用数据库的 RAC 技术，从而提高数据库存储的可用性。

115. 非关系数据存储采用分布式存储

116. 涉及影像文件、标签化数据、缓存的主数据、配置数据、规则数据等均采用Redis、MongoDB 等非关系型数据存储方式，采用的软件技术自身已采用分布式部署方式，在系统使用时，针对采用的这些软件技术部署的节点数多于 3 个即可保证非关系型的存储服务的高可用性。

     综上通过以上技术方案的实施，确保系统的年平均无故障运行时间在 99.9%以上，每年因系统本身问题导致的宕机次数小于 1 次，因系统本身问题出现故障时的恢复时间小于 1 小时。

      

117. 备份恢复解决方案

118. 数据保护系统一体化设备，部署简单，功能强大，为企业避免存储集中后的单点故障，实现数据容灾、应用容灾、文档共享安全管理的统一整体解决方案。

119.  本地数据生产中心

120. 

     •通过光纤传输的数据迁移器，将数据直接写入磁带设备中，实现FC-SAN或IP-SAN环境下的数据备份，备份源点经过光纤交换机写入到磁带设备，进而实现高速备份。

     •驱动器技术，实现多源点、跨平台复杂环境下的FC-SAN方式备份，多平台的备份主机将备份数据写入一个磁带驱动器，从而实现集中、统一的备份和恢复工作。

     •认证与加密：提在线数据备份过程中采用128位加密，如访问和授权控制、磁盘和磁带加密、广域网传输加密方法，配合磁带驱动器的加密技术，可以管理加密磁带驱动器的密钥，提高磁带备份的安全性。

     •D2D2T：先进的磁带读写技术、磁带库机械手控制技术，兼容各主流物理/虚拟磁带库，采用磁盘备份时，数据同样以磁带格写入磁盘，从而轻松实现磁盘到磁盘再到磁带的数据备份。

121. 支持公有云、私有云异地容灾

122. 

     •提供远程容灾备份功能。可选择定时和实时两种技术来实现远程数据保护功能。在定时模式下，可自主选择复制时间间隔;在实时模式下，可实现两地之间的数据完全一致。

     •支持一对一、多对一、一对多、多对多的不同广域网容灾范围。采用数据压缩、断点续传、流量控制和双向缓冲技术，以及重复数据删除，减少网络通信流量90%，提高了数据传输的稳定性和效率。物理位置分离的两台、多台服务器可以相互容灾备份，一旦灾难发生，在异地的数据备份并不会受到波及，确保数据安全。

     •D2D2T：先进的磁带读写技术、磁带库机械手控制技术，兼容各主流物理/虚拟磁带库，采用磁盘备份时，数据同样以磁带格写入磁盘，从而轻松实现磁盘到磁盘再到磁带的数据备份。

     •恢复测试和灾备演练：支持建立备份容灾的物理机或者虚拟机。该功能还可以用于恢复测试和灾备演练，随时验证备份数据的有效性。

      

123.  NAS备份方式

124. NAS（Network Attached Storage：网络附属存储）是一种将分布、独立的数据整合为大型、集中化管理的数据中心，以便于对不同主机和应用服务器进行访问的技术。按字面简单说就是连接在网络上，具备资料存储功能的装置，因此也称为“网络存储器”。它是一种专用数据存储服务器。它以数据为中心，将存储设备与服务器彻底分离，集中管理数据，从而释放带宽、提高性能、降低总拥有成本、保护投资。其成本远远低于使用服务器存储，而效率却远远高于后者。

     根据我公司实际情况，将来采用的备份机制是，在需要定期备份的数据服务器上安装sshserver + rsync 软件，指定需要备份的数据的目录，设定同步周期，通过ssh+rsync加密协议定期的把服务器上的数据备份到NAS服务器上。

     各个系统通用备份方法，重要文件异地机房备份，对大数据、不能中断系统采用分布式，集群部署，能随时恢复。

      

     备份内容	备份方式	最长备份周期
     操作系统（windows Linux）	生成系统快照	1天
     数据库	数据库采用Mysql/oracle，oracle配置为rac或者主备，mysql配置为集群或者主备	1小时
     附件(图片，视频，文件)	Ssh+rsync加密备份，磁盘阵列	1天
     应用程序	Git/svn	1天

125. Linux下oracle备份方案

126. 两台服务器，包含正式环境服务器跟备份服务器，正式环境每天凌晨3点定时通过exp导出全库，再用rsync传输至备份服务器存档

127. 实现scp免密码传输

128. 直接运行scp传输命令，会提示输入密码，要实现无人值守定时运行，就需要让两台服务器的交互能够自动免密，在此通过建立ssh信任关系的方法来实现
     在正式服务器上执行ssh证书生成命令

     ssh-keygen -t rsa

     遇到提示一路回车

     运行完毕后，在/root/.ssh目录下会生成id_rsa，id_rsa.pub两个文件

     登录备份服务器，在用户对应.ssh目录（如/root/.ssh）下新建authorized_keys文件，将正式服务器id_rsa.pub文件的内容追加进去

     在正式服务器上随意新建一个文件，测试scp传输

     scp ./aaa [email protected]:/root/

     现在已经不需要输入密码了，scp免密码传输已经成功

129. 文件备份方案

130. 日常工作中有很多的备份工作，rsync是一个很不错的工具，尝试使用基于ssh免密登陆的方式进行备份，是可行且方便的方法，可用于备份系统，oracle，程序，附件，媒体等文件

     1.A主机root用户对B主机root用户做ssh免密登陆，此过程不再赘述，请参考上述oracle备份步骤。

     2.A主机安装rsync命令：yum install rsync -y

     

     3.在A主机根目录下创建/ceshi目录，B主机根目录下也创建/ceshi目录，并touch一些测试文件。

     

     

     4.执行命令：rsync -a -e "ssh" 192.168.249.145:/ceshi/ /ceshi/，并检查本地/ceshi目录，如果被备份主机的ssh端口修改过，则修改为"ssh -P XXXX"

     

     这样，便将192.168.249.145主机上/ceshi目录下的所有文件同步到了本地目录下的/ceshi，需要注意的是192.168.249.145:/ceshi/  ，这个/，如果有，则表示同步文件目录下的所有文件，如果没有/，则表示下载改目录，-a的意思是不改变文件属主，权限等信息。

     5.应用范围：可以使用rsync对数据库的备份文件，或者其它需要进行备份的数据进行同步，最后，值得一提的是，rsync实现的是自动对比文件的备份，被备份目录是备份目录的子集，自动实现差异备份。

131. 灾难恢复

132. 系统出现故障，导致不能运行的时候，需要有排除故障的预案，以便于及时解决故障并迅速使系统正常运行，下面对可能出现的故障进行列举，并提出故障排除方式。

     故障类型	故障点	备份系统排除恢复方案
     硬件故障	电源、内存等非存储相关设备故障	确定故障点，更换故障配件，如果故障配件没有备份配件，联系服务器生产厂家，让其及时提供； 如果配件发货周期较长，可考虑把同类型服务器的配件暂用替换下，先把数据拷贝出来，然后在其他备用服务器上安装程序，以及恢复数据，使系统尽快的先恢复起来。
     	硬盘或者磁盘阵列故障	如果出现一块硬盘坏了，可以通过替换相同类型的硬盘，服务器自带Raid5功能，将自动修复。 如果多块硬盘出现故障，数据无法读取的时候，首先查找备份文件，如果备份文件较新，比如是一天内的备份数据，此时评估下丢失的数据是否重要或者可以通过其他方式恢复，如果不重要或者可以通过重新录入恢复，则用备份服务器上的数据进行数据恢复；如果数据重要，则可以请专业磁盘数据恢复公司的人过来进行数据恢复。
     软件故障	操作系统故障	Vmware通过备份的快照快速恢复。Docker通过docker快照备份
     	应用程序故障	可以联系应用程序开发，要求进行售后支持，通过svn或者git根据安装程序代码版本通过Jenkins  完成自动化部署。
     数据恢复	数据库	Oracle通过dmp文件或归档回，复，mysql通过bin_log恢复
     	文件	本机通过挂载直接恢复，本地局域网通过rsync快速恢复，远程通过ssh+rsync快速恢复

      

133. 备份数据清理

134. 根据需求和数据量大小，可在备份服务器定时删除旧数据。

     #!/bin/bash
     #删除60天以上备份文件
     location=/data/backup
     find $location  -mtime +60 -print | xargs rm -r