写点什么

玄姐公开课总结【构建基于 ServiceMesh 的普适业务中台架构】

用户头像
魔曦
关注
发布于: 2020 年 06 月 11 日
玄姐公开课总结【构建基于ServiceMesh的普适业务中台架构】

构建基于 Service Mesh 的普适业务中台架构需要解决如下三个问题:

1.Service Mesh 如何实践

2.业务中台如何实践

3.Service Mesh 和业务中台的关系是怎么样的?二者如何结合

ServiceMesh 架构设计与实践

Service Mesh 是微服务架构的 2.0 版本,微服务架构 1.0 版本如何设计的及从 1.0 版本迁移到 2.0 版本企业需要做哪些改变,带给你哪些甜蜜点和痛点

微服务架构如何拆分?

[垂直拆分(业务领域,比如商品、交易、订单等)/水平拆分(网关层、业务逻辑层、公共业务逻辑层、公共数据访问服务层、业务数据访问服务、数据存储层等)] 公共逻辑一定要下沉,个性化能力上升;

网关服务:请求鉴权、协议转化、路由

数据访问服务层需要实现 ORM、CRUD、Sharding,屏蔽底层存储的差异性

公共业务逻辑层(手机发布、图书发布等抽象为商品的发布服务)

公共的部分是那些?(抽取业务中台)

个性化的部分是那些?(特殊逻辑)

同层之间是不会访问,避免了循环依赖,调用层级一定是从上往下的流转

微服务架构图:

存在的问题:各层需要关注服务本身的设计和服务治理功能,业务方不应该关注服务治理,关注了之后会导致业务迭代进度缓慢等问题,解法就是拆,将服务本身设计和服务治理功能从一个 process 拆成两个 process,服务本身、服务治理 sidecar 这也就是 ServiceMesh 要干的事情将两者进行物理隔离或者解耦


业务本身和服务治理功能必须同一台机器(物理机器、虚拟机、k8s pod),为啥同机主要是通信问题(不是同一台机器又回到了 1.0 时代需要服务治理能力了,解决了一个问题又引入了一个问题),同机器就不需要在服务发现与注册等功能了,但是服务本身(Java 语言开发)、服务治理 sidecar(Java/Go 开发),如果两者是跨语言的如何进行通信呢?需要解决两个问题一个是通信协议比如都采用 tcp,tcp 本身就是跨语言的;另外一个问题是传输协议比如 PB,PB 也是跨语言的;因此也就解决了服务本身和服务治理 sidecar 通信的问题;但是服务治理 sidecar 如何知道要调用那个服务的 sidecar 呢?这就需要服务本身在调用服务治理 sidecar 的时候告诉要调用那个服务的 sidecar,业界的通用解决方案就是通过定长 header+变长 body 来搞定,定长 header 里面有个字段标识为需要调用的服务的 sidecar;

Service Mesh 架构图:

按照以上架构就可以从微服务架构演进到 ServiceMesh 架构,架构的逻辑没有变化,只是增加了一个 Sidecar。

ServiceMesh 落地方案

主要有企业自研和使用开源的组件;

1.企业自研(RPC 改造成 sidecar、sidecar+服务注册中心组成了服务治理平台,服务注册中心、数据收集中心、Mesh 管理平台等都不需要变化,只是需要调整数据上报方)

2.开源组件 Istio1.5.2

ServiceMesh 架构

思考点:

1.什么是 VIP?VIP 的作用是什么?

2.LVS 四层、Nginx 七层各起到什么作用?

业务中台架构实践普适设计哲学

思考:

中台与平台是什么关系?

平台与操作系统什么关系?


芬兰移动游戏公司 SuperCell 以小前台方式组织开发团队,1~2 周可以开发出一个独立的游戏,沉淀了业务中台、算法中台、数据中台、技术中台;


业务中台是一种业务模式,而业务模式的落地需要一种基础架构来支持,这套基础架构既可以是微服务架构 1.0 或者 ServiceMesh 架构等,因此 ServiceMesh 架构是业务中台落地的一种技术架构实现方式

业务中台如何落地

业务中台落地->通用业务下沉为公共的服务

1.新增业务如何一键接入众多业务中台服务?

业务配置中心(新业务生成业务的唯一编码,后续业务操作都基于该编码进行流转)、规则配置中心(主要负责针对具体业务规则的配置,比如新业务编码为 XXX 要接入搜索,需要告诉搜索那些字段需要建立索引等,建立索引等字段就是规则配置),分发中心(将配置中心的规则分发到具体的业务线)


思考点:上图业务是同步接入,如何异步接入呢?


2.业务中台数据存储如何支持多业务接入?

(比如商品数据包含通用的部分、个性化(标签)部分等)

业务中台数据统一存储,前台业务独立存储

业务公共数据表+业务个性化扩展数据表(如何设计变的更通用化)



以上的设计是基于将业务按照数据类型进行抽象,比如 String、Long、double 等,且底层的存储是 MySQL,因此会涉及到分别、分库。那么如何解决一致性问题呢?如果存储变成 MongoDB、TIDB 有该如何设计呢?

商品中台淘宝、京东、当当的数据是如何存储的呢?

ServiceMesh 构建 X2C 电商业务中台架构设计与实践

常见案例分析,商品详情页面等;

总结

架构设计的本质:降本增效,别炫技浪费公司资源。

用户头像

魔曦

关注

我思故我在! 2018.01.15 加入

凡事有交代,件件有着落,事事有回音。

评论

发布
暂无评论
玄姐公开课总结【构建基于ServiceMesh的普适业务中台架构】