# V8环境规划和安装部署指南
# V8部署架构说明
# V8微服务部署架构简介
V8 PaaS平台提供基于SpringBoot框架扩展开发的统一微服务基础框架支撑体系，包括微服务框架、持久化及数据源、对象存储、缓存、消息、事件、日志、线程池、分布式锁、脚本引擎等组件。
V8 PaaS平台支持部署在私有云、公有云或混合云环境，整套部署方案采用主流的云原生架构：
- 使用Kubernetes容器平台，运行和管理所有V8微服务应用程序，提高了应用的可扩展性和弹性。
- 使用Nginx，作为V8应用的HTTP请求入口，提供负载均衡与反向代理服务。
- 使用关系型数据库（如MySQL），用于存储和维护V8应用的结构化数据，保证数据的一致性和安全性。
- 使用Nacos，进行V8的统一配置管理和服务注册与发现，支持动态配置并简化服务治理。
- 使用对象存储（如MinIO），存储和管理V8应用的非结构化数据（例如附件），以满足大规模数据的存储需求。
- 使用Redis分布式缓存服务，缓存V8的热点数据，提升数据访问速度并降低数据库负载。
- 使用Kafka消息中间件，实现V8消息的生产和消费，确保消息处理的高效性和可靠性。
- 使用ElasticSearch（ES）搜索引擎，提供强大的全文搜索功能、数据分析和可视化支持，尤其适用于实时日志分析、监控和复杂查询。
- 使用ClickHouse列式数据库，进行报表的实时数据分析和处理，支持大规模数据的高性能查询。
- 使用Gitlab进行代码版本管理，维护UDC低代码平台建设的程序代码。低代码平台生成的镜像由V8中的沙箱微服务完成编译，沙箱中集成了Maven、NodeJS等工具。
- 使用Harbor，管理所有V8微服务的镜像，包括UDC低代码平台自建的镜像，保障镜像存储的安全和效率。
# V8服务建设整体步骤
基于V8微服务部署架构规则，如需部署并启动V8服务，需要完成如下步骤：
第一步，规划部署方案：确定用户的V8使用需求，再依据需求整理出所需资源和部署方案（详见[V8规划部署方案]章节）。
第二步，部署中间件：待客户准备与之匹配的资源后，根据V8架构要求部署产品所需中间件（所需中间件详见[V8依赖中间件]章节）。
第三步，部署V8应用程序：下载V8安装工具，使用工具连接已部署的中间件服务，进行V8程序安装和初始化。
第四步，登录系统：登录V8系统，进行租户初始化、沙箱创建等操作后即可使用。
第五步，重复第二步到第四步部署第二套，甚至第三套环境（部署多套环境原因见“规划部署方案”章节）。
# 关于高可用
高可用（High Availability, HA）指的是一个系统或组件在正常和故障情况下能够持续运行并提供可接受性能水平的能力。高可用性的重要性在于确保系统在大多数情况下能够不间断地提供服务，从而减少停机时间对业务和用户的影响。
我们推荐V8关键服务采用高可用部署方案，以获得稳定、快速和可靠的服务体验，但高可用部署所需服务器资源更多。
以数据库为例简短介绍什么是高可用？
数据库单机即可供V8应用进行读写使用，但如果数据库服务器硬件损坏会因为V8读不到数据从而导致系统全面不可用。为了防止数据库单台服务器故障（俗称单点故障）引发的全面异常，可以使用2台数据库主备模式运行，当1台主数据库故障后，另1台数据库服务还能继续供V8连接使用，从而确保了服务的可用性。
# V8规划部署方案
# 规划部署方案重要性
V8云原生微服务架构不同于传统的单体部署架构，所需中间件数量和资源均超过单体部署架构，先进的技术架构使其扩展能力和并发支持能力更加优秀。
基于此优势，V8客户的环境类型、在线人数跨度也更大，规划合理的部署方案才能最大程度发挥V8平台的价值。
规划部署方案适合参与服务运维部署的技术顾问主导！
# 规划部署方案工具和关键步骤
部署方案可参考《COP-V8服务器资源评估 (opens new window)》工具中的模板进行规划评估，关键步骤为：
第一步，参考“资源沟通参考模板”调研客户环境情况，并根据客户环境做整体方案预设计
第二步，参考“服务推送关系模板”以及用户需求，规划客户需要几套环境，以及环境推送关系
第三步，参考“微服务部署资源”以及第一步预计在线人数，初步评估服务器所需资源
第四步，参考“微服务清单（模板）”以及用户需求，规划每套环境需要使用哪些微服务，再根据所需资源测算及校正K8S资源
第五步，参考“服务器资源确认清单（模板）”以及前几步的综合评估，汇总最终部署方案
# 规划第一步：资源沟通
规划部署方案第一步：收集客户的环境信息和需求。参考《COP-V8服务器资源评估 (opens new window)》工具中的“资源沟通参考模板”页签与客户进行逐个需求沟通，主要沟通内容和目的：
注：V8能在什么CPU芯片、什么操作系统、什么数据库下运行？V8支持哪些信创Web中间件？ 详见《V8非功能性兼容支持情况 (opens new window)》
| 沟通事项 | 目的 |
|---|---|
| 基础设施平台和架构 | 调研客户使用什么CPU架构、什么云平台（比如信创ARM则要考虑资源是X86的1.2倍） |
| 操作系统要求 | 调研客户使用什么操作系统：信创麒麟？RedHat系列？Euler系列？（部分偏门系统可能导致部署不兼容） |
| 中间件要求 | 1、调研需要自建哪些中间件，是否存在高可用需求，单机和高可用所需资源不同 2、微服务依赖的Web中间件，默认内嵌开源Tomcat，如客户使用信创东方通等内嵌版，要告知客户这个需联系信创厂商购买 |
| 数据库类型要求 | 调研客户使用什么数据库：默认社区版MySQL，如客户使用信创达梦、金仓，要告知客户这个需联系信创厂商购买 |
| 服务器网络要求 | 调研客户服务器群的网络情况，需要确保后台服务在同一局域网 |
| V8环境套数 | 非常关键：调研客户是否使用UDC低代码或表单搭建，如使用则需要至少两套环境，并设置推送关系（实施/开发→生产） |
| 计划部署的V8微服务数量 | 调研客户需要使用哪些产品功能：协同？公文？公告？功能越多所需服务器资源越高，需要根据需求做精准测算 |
| V8在线用户数 | 调研客户峰值在线人数，以便根据在线人数参考手册给服务器整体推荐 |
| 需要使用哪些第三方服务 | 调研客户使用哪些第三方服务：在线预览？在线编辑？OCIP？AI？这些服务都需要额外的资源申请（不在V8默认资源范围内） |
| 其它特殊要求 | 调研客户是否使用域名管理、是否https等等，以便做统一规划 |
模板示例截图：
# 规划第二步：环境标识和推送设计
规划部署方案第二步：参考《COP-V8服务器资源评估 (opens new window)》工具“服务推送关系模板”确定客户环境数量和推送关系。
如使用UDC低代码或表单搭建，V8要求至少两套环境： 第一套开发实施环境，第二套生产环境。UDC低代码开发设计和测试在第一套开发实施环境进行，测试充分后将编译包推送到生产环境，第二套生产环境直接使用设计好的低代码应用。
详细评估需要使用几套环境，不同环境的作用参考文档：
V8多套环境设计和推送规则视频：协同云-赋能中心-致远学院，搜索“V8多套环境设计”
V8 5.x版本多套环境推送解决方案 https://docs.qq.com/slide/DS25tY0hKSWFScW5w
V8 5.x版本多套环境推送操作文档： https://docs.qq.com/doc/DS05EbmJKYWNLcGt1
V8 5.x版本环境分配规则逻辑图：
# 规划第三步：初步评估部署资源
规划部署方案第三步：参考《COP-V8服务器资源评估 (opens new window)》工具“微服务部署资源”以及客户预计在线人数，规划服务器所需资源：
- 如果是POC演示，不涉及压测，则只需要取POC资源列
- 如果是正式环境资源申请，则要结合第一步的需求调研评估客户要几套环境
注意：这一步只是整体资源的预估，在完成整体资源预估后，还需要结合后续步骤进行精准测算微调资源。
以生产8000人在线+使用UDC低代码场景为例，需要至少准备两套环境，所需资源初评需要包含下图两个红框的内容：
扩展说明：
- 当前资源推荐不是绝对的，项目上可根据情况灵活调整，比如客户有自己的对象存储服务，则不需要申请MinIO资源
- 资源表格中存在多个服务（如Nacos、Redis、Kafka）占用1台服务器的场景，表示这三个服务可以部署在同一台服务器
- 1副本表示每个微服务在K8S下仅存活一个pod，2副本表示每个服务在K8S下存活两个pod，多副本能实现V8的高可用，但对硬件资源要求也是成倍增加
- 大于1000在线用户后，一般推荐核心服务实现高可用，高可用所需资源更多。客户可以不采纳建议，但要告知客户单点故障风险
- 当前资源采用X86硬件测算，如果是信创环境，需要考虑增加20%以上的硬件资源。参考资料：【信创服务器海光和鲲鹏差异化及性能测试对比分析 (opens new window)】（信创海光和鲲鹏处理器在TPS性能上相较Intel处理器有40%~50%性能差距）
# 规划第四步，测算微服务资源占用
规划部署方案第四步，参考《COP-V8服务器资源评估 (opens new window)》工具“微服务清单（模板）”以及用户需求，填写每套环境需要使用哪些微服务，再根据所需资源测算及校正K8S资源：
- 微服务均在K8S的Worker节点下运行，注意微服务测算资源总和不能超过K8S的Worker节点服务器资源总和的70%（留20%~30%做紧急资源占用）
- V8微服务主要分三类：平台类、标品应用、UDC低代码。表格中有“是否必装”，其中平台类是必装，其它类是根据客户需求可选安装，安装越多资源要求越高。
- 如果涉及UDC低代码应用，需要测算低代码应用数量，建议至少5个以上，每个低代码应用就是一个微服务（一个pod），故需要充分预估低代码占用资源
- 在线工具最终能生成总资源，将资源总和÷70%就是最终K8S Worker节点服务器的资源，此时可以修正第三步初评估的K8S Worker节点资源。
- 测算微服务资源工具非常关键，用户问“为什么要这么多K8S资源”时，就可以拿着这个测算明细做依据进行沟通！
# 规划第五步，输出资源评估报告
规划部署方案第五步：参考《COP-V8服务器资源评估 (opens new window)》工具“服务器资源确认清单（模板）”以及前几步的综合评估，给出最终的资源评估报告：
- 填写服务器架构、操作系统、CPU核心数、内存、数据盘大小、服务器用途、推荐版本、参数要求
- 其中每个中间件要求的版本和参数要求，参考《COP-V8服务器资源评估 (opens new window)》工具“中间件版本和参数要求”里面的说明，尤其是客户自己维护中间件场景，需要将要求发给客户
- 如存在多套环境，每套环境的要求均列出来
- 通过一页内容完成资源汇总和报告，同时汇总报告也可以作为后续部署维护参考材料（后期加上服务器IP、连接帐号密码）
# 规划评估示例
第一步，资源沟通：
客户采用私有云环境、信创ARM架构CPU、所有中间件和K8S均自建、数据库使用达梦、操作系统麒麟V10。
功能需求：新闻、公告、公文，需要UDC低代码平台。 预计在线人数5000人。
第二步，环境标识和推送设计：
由于客户涉及UDC应用，按V8 5.x版本环境要求，需要两套环境： 第一套开发实施环境，第二套生产环境。
推送方向：开发实施环境（设计UDC应用）→生产环境（使用UDC应用）
第三步，初步评估部署资源：
参考《COP-V8服务器资源评估 (opens new window)》工具“微服务部署资源”，取非生产环境和生产环境3000-5000在线的资源清单作为初步评估资源。
非生产环境全部单机，无需高可用；生产环境核心应用（Nacos、Redis、Kafka等）实现高可用，数据库由达梦厂商提供高可用方案。
由于客户使用信创架构，故所有资源在当前X86配置推荐基础上增加20%。
第四步，详细测算微服务资源占用：
参考《COP-V8服务器资源评估 (opens new window)》工具“微服务清单（模板）”，录入用户需要使用的标品应用和UDC应用数量，测算最终需要多少K8S Worker节点资源。
客户必须部署x个平台微服务，x个标品应用。按5000在线资源推荐，所有服务需要实现高可用，故全部2副本（所有pod资源翻倍）。另外，UDC预估建设10个应用，每个应用2副本。以上综合测算所需服务器资源为xxx核心xxx内存，再按照30%余量，最终配置超出初步评估的资源，需要修正K8S Worker资源为x台xx核心xx内存。
第五步，生成评估报告：
基于前面几步的沟通评估，客户最终的资源评估报告如下（截图仅供示例参考）：
# V8安装部署方案
# V8依赖中间件服务
V8部署需要哪些依赖服务？ 以下为V8云原生微服务平台部署所需中间件：
| 编号 | 开源中间件 | 作用 |
|---|---|---|
| 1 | Nginx | 反向代理、负载均衡、请求统一入口 |
| 2 | Kubernetes | 容器平台，所有V8基础代码及低代码应用在平台里运行 |
| 3 | MySQL | 数据库，存储V8所有业务结构化数据 |
| 4 | Nacos | 配置中心、服务注册发现，管理V8配置及服务 |
| 5 | MinIO | 对象存储，存储V8所有业务非结构化数据 |
| 6 | Redis | 缓存数据库，存储V8缓存数据 |
| 7 | Kafka | 分布式消息中间件，实现V8消息生产消费高效管理 |
| 8 | ElasticSearch | 检索数据库 |
| 9 | ClickHouse | 列式数据库，用于报表实时数据分析处理 |
| 10 | Gitlab | 代码仓库，用于低代码平台代码版本管理 |
| 11 | Harbor+Docker | 镜像仓库 |
注意：
- 以上为私有化部署自建中间件推荐，均采用主流的开源组件，具体推荐的中间件版本见《外部依赖服务清单 (opens new window)》
- 中间件依赖必要的服务器资源，不同需求不同在线用户数所需服务器数量和配置不同，默认推荐详见《微服务部署资源 (opens new window)》
- 所有服务可以单机部署运行，也可以高可用部署运行
- 如客户在公有云或混合云运行，可使用云服务商提供的与开源组件相匹配的中间件解决方案
- 相关中间件服务默认由客户提供和维护，标准产品不提供开源中间件的安装包
- 标准产品提供的物料：V8应用程序安装升级工具和V8微服务程序镜像包，相关物料需要在以上中间件运行的前提下才能使用
- 开放平台《V8运维知识库 (opens new window)》提供了开源中间件的部署指导手册可供参考
不同服务实现高可用的方案如下：
| 编号 | 开源中间件 | 高可用方案 |
|---|---|---|
| 1 | Nginx | 2台服务器，每台均部署nginx+keepalived，如没有前置LB服务则需要准备VIP地址 |
| 2 | K8S Master | 3台K8S Master节点实现高可用 |
| 3 | K8S Worker | N台K8S Worker节点存放微服务应用，每个应用2副本可实现微服务应用的高可用 |
| 4 | MySQL | 数据库按厂商专业意见为准，比如主备模式两台服务器 |
| 5 | Nacos | 3台服务器，每台部署Nacos，并且集群模式Nacos依赖MySQL数据库做数据存储，可以复用客户数据库环境下的MySQL服务（如客户不是MySQL，则在数据库服务器部署一个低配置MySQL供Nacos使用） |
| 6 | MinIO | 最低4个节点高可用，每个节点最少2块相同大小磁盘（纠删码要求），最好使用大厂自带的OSS、OBS |
| 7 | Redis | 3台服务器，每台部署两个Redis，通过三主三从实现高可用 |
| 8 | Kafka | 3台服务器，每台部署Kafka实现高可用 |
| 9 | ElasticSearch | 3台服务器，每台部署ES实现高可用 |
| 10 | ClickHouse | 3台服务器，每台部署ClickHouse实现高可用 |
| 11 | Gitlab | 该服务生产环境不涉及，故无需高可用，并且也没有高可用方案 |
| 12 | Harbor+Docker | 该服务正常也不涉及高可用 |
# V8微服务部署步骤
一、V8微服务整体部署步骤为：
在确保所有中间件服务部署完成后，再参考《V8微服务安装部署手册 (opens new window)》进行V8微服务程序的安装部署及启动。
第一步，部署安装工具：将安装工具部署包上传至服务器、解压并启动，通过WEB浏览器可视化操作安装工具页面
第二步，设定环境基础信息和定义环境标识（名词解释详见“环境标识”相关章节）
第三步，联系商务/运营获取license并配置许可证书
第四步，V8制品准备：将V8制品包上传至安装工具所在服务器并初始化（制品即V8微服务相关程序镜像包）
第五步，按需选择标品应用并配置K8S及中间件信息
第六步，部署安装工具自动检查所需中间件连通性和配置信息，检查通过后自动部署应用
二、V8微服务部署安装工具执行核心逻辑：
- 可视化配置、检查V8依赖的所有中间件服务信息
- 可视化管理V8标品微服务镜像，并自动发布到K8S容器平台
- 将V8每个标品微服务作为一个POD在K8S Node下运行，实现服务自动发布
# V8方案规划经验总结
规划总结分享视频：协同云-赋能中心-致远学院，搜索“V8环境规划火种分享”，建议详细学习。
V8一般要求2套环境，每套环境都需要部署对应中间件和微服务
“微服务部署资源”表格仅仅是不同在线用户数通用配置参考，为了精确测算资源还应利用“微服务清单（模板）”
测算微服务资源时一定要预留UDC资源！
资源推荐也并非绝对，用户的使用习惯不同所需资源也不同，在上线前最好做一次压力测试，以便发现环境潜在风险
前期资源申请建议多提一点，用户会有砍资源的习惯，但最低限度要保留，避免减配后服务出现问题
所有中间件原则是客户提供，标品出厂不带中间件程序，项目组自建需要跟客户谈建设维护成本，避免后续不必要的麻烦
每个V8微服务均内置了开源的Tomcat中间件，如客户有信创需求需要自行采购信创Web中间件Springboot内嵌版，注意信创中间件一般按套数计费，V8下运行了多少个微服务就要多少套中间件！
产品适配在线预览和在线编辑服务最全面的是金山WebOffice中
V8支持多租户，多租户下挑数据库，一般MySQL、金仓MySQL模式、达梦MySQL模式可用
所有涉及到微服务的资源评估时，都需要预留一部分空闲资源，用于pod切换拉起以及预估低代码要生成的应用数的规模。例如预留服务器资源的1/3左右。
K8S只要是高可用，必须3、5、7台单数，避免脑裂，这个专业术语是加分项，可以AI了解详情
部署模式的选型应该在规划阶段就明确下来，例如二进制部署、容器化部署。poc可考虑全容器化（docker）部署，生产环境考虑二进制（native）部署。
对于操作系统、中间件、数据库的版本推荐，不要写中间件官方最新版，最新的没评估测试过的，一定是用稳定测试版本。
数据库尽可能要求厂商实施部署或使用云服务产品。
minio对象存储也可随时扩容，扩容方式包括lvm逻辑卷、节点扩容、磁盘扩容。但是，如果客户有现成类似OSS、OBS、ceph之类的，建议直接使用。
NFS文件共享，从性能或高可用考虑，可使用客户提供的，或使用ceph提供的。
如果满足客户合规要求，在不影响性能的情况下，部分服务可以考虑复用。例如harbor、NFS等。
可能大家没注意到内外网访问和域名访问的情况。这部分需要提前与客户沟通规划，避免部署实施时随意变动影响项目推进。
根据实际场景把拓扑图画出来，不能仅使用v8的那个架构关系图。才便于清晰的理清理顺整个系统的架构、数据流向。
总之，要从整套v8业务系统的全局观、总体性、系统性等方面进行考虑，基于 实际业务需求+客户客观条件 来进行规划设计。
快速跳转
