玄姐公开课总结【构建基于ServiceMesh的普适业务中台架构】
构建基于Service Mesh的普适业务中台架构需要解决如下三个问题:
1.Service Mesh如何实践
2.业务中台如何实践
3.Service Mesh和业务中台的关系是怎么样的?二者如何结合
ServiceMesh架构设计与实践
Service Mesh是微服务架构的2.0版本,微服务架构1.0版本如何设计的及从1.0版本迁移到2.0版本企业需要做哪些改变,带给你哪些
微服务架构如何拆分?
[垂直拆分(业务领域,比如商品、交易、订单等)/水平拆分(网关层、业务逻辑层、公共业务逻辑层、公共数据访问服务层、业务数据访问服务、数据存储层等)] 公共逻辑一定要下沉,个性化能力上升;
网关服务:请求鉴权、协议转化、路由
数据访问服务层需要实现ORM、CRUD、Sharding,屏蔽底层存储的差异性
公共业务逻辑层(手机发布、图书发布等抽象为商品的发布服务)
公共的部分是那些?(抽取业务中台)
个性化的部分是那些?(特殊逻辑)
同层之间是不会访问,避免了循环依赖,调用层级一定是从上往下的流转

存在的问题:

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

按照以上架构就可以从微服务架构演进到ServiceMesh架构,架构的逻辑没有变化,只是增加了一个Sidecar。
ServiceMesh落地方案
主要有企业自研和使用开源的组件;
1.企业自研(RPC改造成sidecar、sidecar+服务注册中心组成了服务治理平台,服务注册中心、数据收集中心、Mesh管理平台等都不需要变化,只是需要调整数据上报方)
2.开源组件 Istio1.5.2

ServiceMesh架构

思考点:
1.什么是VIP?VIP的作用是什么?
2.LVS四层、Nginx七层各起到什么作用?
业务中台架构实践普适设计哲学
思考:
中台与平台是什么关系?
平台与操作系统什么关系?
芬兰移动游戏公司SuperCell以小前台方式组织开发团队,1~2周可以开发出一个独立的游戏,沉淀了业务中台、算法中台、数据中台、技术中台;
业务中台如何落地
业务中台落地->
1.新增业务如何一键接入众多业务中台服务?
业务配置中心(新业务生成业务的唯一编码,后续业务操作都基于该编码进行流转)、规则配置中心(主要负责针对具体业务规则的配置,比如新业务编码为XXX要接入搜索,需要告诉搜索那些字段需要建立索引等,建立索引等字段就是规则配置),分发中心(将配置中心的规则分发到具体的业务线)


思考点:上图业务是同步接入,如何异步接入呢?
2.业务中台数据存储如何支持多业务接入?
(比如商品数据包含通用的部分、个性化(标签)部分等)
业务中台数据统一存储,前台业务独立存储
业务公共数据表+业务个性化扩展数据表(如何设计变的更通用化)



以上的设计是基于将业务按照数据类型进行抽象,比如String、Long、double等,且底层的存储是MySQL,因此会涉及到分别、分库。那么如何解决一致性问题呢?如果存储变成MongoDB、TIDB有该如何设计呢?
ServiceMesh构建X2C电商业务中台架构设计与实践
常见案例分析,商品详情页面等;
总结
架构设计的本质: