• 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏吧

直播了!构建基于ServiceMesh的中台架构!

大数据 开发技术 2周前 (05-12) 19次浏览

【第一部分-ServiceMesh】

服务网格 (ServiceMesh)这两年异常之火,号称是下一代微服务架构。

ServiceMesh到底解决什么问题呢?

微服务架构中,随着数据量不断增大,吞吐量不断增加,业务越来越复杂,服务的个数会越来越多, 分层会越来越细 ,除了 数据服务层 ,还会衍生出 业务服务层前后端分离 等各种层次结构。

不断发现主要矛盾,抽离主要矛盾,解决主要矛盾,架构自然演进了,微服务架构, 潜在的主要矛盾会是什么呢?

引入微服务架构,一般会引入一个RPC框架,来完成整个RPC的调用过程。

如上图粉色部分所示,RPC分为:

  • RPC-client,它嵌在调用方进程里

  • RPC-server,是服务进程的基础

如此这般,越来越多和RPC,和微服务相关的功能,会被加入进来。

例如: 负载均衡

如果要扩展多种负载均衡方案,例如:

  • 轮询

  • 随机

  • 取模

  • 一致性哈希

RPC-client需要进行升级。

例如: 数据收集

如果要对RPC接口处理时间进行收集,来实施统一监控与告警,也需要对RPC-client进行升级。

又例如: 服务发现

服务新增一个实例,通知配置中心,配置中心通知已注册的RPC-client,将流量打到新启动的服务实例上去,迅猛完成扩容。

再例如: 调用链跟踪

如果要做全链路调用链跟踪,RPC-client和RPC-server都需要进行升级。

上述功能,其实都不是业务功能,所以 互联网公司一般会有一个类似于“架构部”的技术部门去研发和升级相关功能 ,而业务线的技术部门直接使用相关框架、工具与平台,享受各种“黑科技”带来的便利。

完美!!!

理想很丰满,现实却很骨感,由于:

  • RPC-client,它嵌在调用方进程里

  • RPC-server,是服务进程的基础

往往会面临以下一些问题:

  • 业务技术团队,仍需要花时间去学习、使用基础框架与各类工具,而不是全心全意将精力花在业务和产品上

  • client要维护m个版本, server要维护n个版本,兼容性要测试m*n个版本

  • 如果要支持不同语言,往往要开发C-client,Python-client,go-client,Java-client多语言版本

  • 每次“黑科技”的升级,都需要推动上下游进行升级,这个周期往往是以季度、半年、又甚至更久,整体效率极低

画外音: 兄弟,贵司推广一个技术新产品,周期要多长?

这些耦合,这些通用的痛点,有没有办法解决呢?

一个思路是, 将服务拆分成两个进程 ,解耦。

  • 一个进程实现业务逻辑(不管是调用方,还是服务提供方), biz ,即上图白色方块

  • 一个进程实现底层技术体系, proxy ,即上图蓝色方块

  • biz和proxy共同诞生,共同消亡,互为 本地部署 ,即上图虚线方框

  • biz和proxy之间,为 本地通讯 ,即上图黑色箭头

  • 所有biz之间的通讯,都通过proxy之间完成,proxy之间才存在 远端连接 ,即上图红色箭头

这样就实现了“ 业务的归业务,技术的归技术 ”,实现了 充分解耦 ,如果所有节点都实现了解耦,整个架构会演变为:

  • 绿色为biz

  • 蓝色为proxy

整个服务集群变成了网格状,这就是ServiceMesh服务网格的由来。

【第二部分-中台】

“小前台,大中台”是很多公司为了快速落地业务,进行的组织变革与系统架构变革。 中台的目的是复用 :业务复用,组织复用,系统复用。

要想落地中台,一定要有组织机制支持。 组织不变,光系统架构变,各研发团队职责不清,反而会形成各自为战的局面,各占山头,重复建设,变成包袱。 中台战略,一定是自上而下推动的

当然, 中台战略,未必适合所有公司么。 例如:初创公司,业务单一的公司,产研团队较小的公司,并不适合中台。中台战略,特别适合 有一定规模,有多块业务 ,或者 希望快速进行业务创新尝试 的公司。中台战略的落地,能够最大程度的“减少重复建设轮子”。

相对通用的业务,都有做成中台的可能性 。例如:用户,订单,支付,商品,营销等通用的业务模块,非常适合做中台。

【福利来了】

活动 :直播

话题 如何利用ServiceMesh技术,快速构建中台架构

时间 :今晚20:00

嘉宾 :孙玄

扫码 参与今晚直播

1.99 ,买不了吃亏,买不了上当,获取一个和大神当面聊架构的机会。

阅读原文 ,直接参与。


喜欢 (0)