java大规模并发，高可扩展性，高可维护性Java应用系统视频网盘下载

（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）

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

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. 提供相关的管理功能，如批量处理管理、日志管理等
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技术方案。
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 root@192.168.x.x:/root/

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

• 文件备份方案
• 日常工作中有很多的备份工作，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实现的是自动对比文件的备份，被备份目录是备份目录的子集，自动实现差异备份。

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

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

   

• 备份数据清理
• 根据需求和数据量大小，可在备份服务器定时删除旧数据。#!/bin/bash
  #删除60天以上备份文件
  location=/data/backup
  find $location  -mtime +60 -print | xargs rm -r