您现在的位置是：首页 > 文章详情

精选案例 | 企业级Paas平台HZERO与互联网应用体系再次携手、深度融合，有力支撑企业数字化建设平稳落地

日期：2022-11-15点击：404收藏

随着公司不断地开疆扩土，遇到的机会也越来越多，与机会并存的挑战也愈日俱增，在面对传统行业对系统性能要求不那么高的情况下，互联网行业早已提出了更高的要求。该互联网大厂作为互联网行业佼佼者中的一员，其内部技术栈体系独立，同时有着自己较高的技术规范和技术标准，对Hzero平台接入其内部技术体系提出了比较大的挑战。

原有框架与融合框架

原HZERO框架

融合后框架

其中黄色的方块代表着该互联网大厂内部技术栈体系

服务监控

自研监控平台提供面向基础设施和应用程序（包括服务端、Web前端以及移动端）的监控服务，通过自研监控平台可以轻松地分析出应用系统的相关接口是否能贴合自身的技术要求（例如Tp95需保证在1秒之内）。经过分析能够保持自研监控平台与Hzero-admin原生体系并存。
注册中心

自研的注册中心为业务提供了标准化微服务治理解决方案，能够轻松实现服务注册发现、负载均衡、容错处理、降级熔断、灰度发布、调用数据可视化等服务治理功能。同时能够保持自研注册中心与Hzero-register原生体系并存。
配置中心

自研的配置中心则直接替换了Hzero-config原有的配置中心。
分布式调度

自研的分布式调度平台替换了原有的Hzero-scheduler调度平台。
消息平台

自研消息平台则与与Hzero-message服务并存。
数据库

将Mysql替换为自研的Mysql，可以简单的将自研Mysql理解成是数据库层面的中间件（例如SharidingProxy这种DB层面的代理），为后期数据增长做读写分离/分库分表时对服务层能够无侵入式改造，同时自研Mysql也是面向数据库层面的监控，可实时针对慢Sql、大事务进行预警通知。
中间件

✔ 自研Redis-Cluster是基于Redis-Cluster模式进行二次开发的大型分布式缓存系统，此次需要将Redis集群替换成自研Redis-Cluster集群。

✔  原有的Minio对象存储转为接入了该互联网大厂提供的S3文件分发平台。

✔  自研Kafka：引入自研的Kafka保障了系统之间的解耦、异步通信以及削峰填谷。

✔  在互联网相关的技术标准要求下通过Binlog数据同步的方式，将多张表打平为一张宽表同步至Elasticsearc。
代理服务

与外部系统集成时引入了Base-support/support-api两个服务作为代理服务

以上，从架构调整的角度来看，需要替换、改造的服务众多，同时中间件及中间件sdk的融合导致的依赖冲突也是一个不容小觑的问题，下面笔者简单的介绍一下，需要如何去适应和融合该互联网大厂内部的技术栈。

融合边界的划分依据

无论是服务的替换或者是服务的合并，原则是原有基础的微服务架构下注册中心、登录认证服务、配置中心、平台治理、网关等服务不允许替换或者合并，可支持同时存在。

例如该互联网大厂这边为了监控流量，提出了需要将网关替换为对应服务，那么相应的方案就可以是“双网关”同时存在，前端可以将请求转发到该互联网大厂前置网关，该互联网大厂前置网关将请求代理到Hzero平台的网关，当然也会出现一些其他的问题，例如Hzero-oauth服务进行跳转时需要去调整重定向的地址。

服务替换

以下是可替换服务之间的一个关系（可替换服务与内部自研服务并存）：

服务合并

出于降低部署资源的考虑，HZERO平台支持除核心架构微服务外的服务合并功能，以降低客户的资源投入。

方案一：

方案二：

考虑到Hzero-iam服务对比其他例如导入、消息、文件等服务的重要性，Hzero-iam不参与服务的合并，做到节点冗余，保证服务的高可用性，最终采用方案二作为合并方案。

服务合并可直接参考官方文档：HZERO指导手册

若已通过分离部署的方式对服务进行部署，但后续需调整至聚合服务，在具体的操作过程中有以下几个点需要进行补充（否则服务启动后会出现报错的情况）：

Mysql清理Hadm_service_route(合并的服务数据)/Hadm_notice_publisher表
Redis清理Hadm:service:instance/Hadm:routes

整合中遇到的挑战

为了迎合在架构层面的调整，在做具体实现时涉及到与原有基础服务或者是中间件冲突时，需要做到相应的改造，为了将改造点降至最低，我们采用以下策略进行：

中间件或是基础服务与该互联网大厂架构冲突时，采用适配器策略调整，例如我们接入自研Redis集群时，他并不是使用业界Spring提供的能力接入Redis集群，而自身是有着一套适配的Sdk，因此针对于系统中原有使用Spring体系接入的全部要进行改造，我们的设想是通过中间的适配层把业务层面的调用进行隔离，降低改造成本。

由于与外部系统进行集成通讯时，该互联网大厂采用的是结合自研注册中心的服务发现进行的Thrift通信，为了保障对原有微服务模块而减少侵入，我们通过在代理服务（新模块，类似于接口平台）上集成Thrift通信协议，除了保证系统间的解耦，同时也在最大程度上避免了Maven依赖冲突以及后续升级时不必要的麻烦。

包括但不限于以上关于Hzero企业级Paas平台在某互联网大厂进行技术栈融合所面临的遭遇，除了服务融合、服务替换、中间件以及中间件SDK的替换，在这个过程中同时也面临了例如对产品高性能要求的问题（单接口Tp95响应1秒之内，慢Sql1秒之内）。

能够与某互联网大厂技术体系成功融合这也反映出Hzero企业级数字平台的灵活性与兼容性，另一方面也体现了我们技术人员遇到问题解决问题的决心。