ServiceMesh演进之路

  • 简单架构
  • Q:随着业务发展,系统臃肿
  • A:微服务化,拆分成多个系统
  • Q:  数据库瓶颈
  • A:  垂直拆分,不同业务不同库
  • Q:  某个业务量比较大,单库承载不了
  • A:水平拆分 (首先是最小的库的数量,可以通过业务峰值 TPS 除以单库容量上限 TPS 来计算。然后是最小的表的数量,可以通过单位时间业务量乘以存储时长再除以单表的容量上限来进行计算。)
  • Q:服务化,分布式事务问题
  • A:TCC 框架(try confirm cancel) confirm有补偿机制
  • Q:异步消息的事务
  • A:在事务消息里面,发起方会在一个本地事务中去发送一个消息,SOFA 的消息中心接收到这个消息之后,会落到消息中心的存储里面,但是这个时候,消息中心并不会向订阅方投递消息;等到发起方的本地事务结束,会自动给消息中心一个通知,告诉消息中心本地事务已经提交或者回滚,如果消息中心从发起方得到的通知是事务已经提交,就会将消息发送给消息的订阅方,如果消息中心从发起方得到的通知是事务已经回滚,那么消息中心就会从存储中将消息删除掉。当然,发起方给消息中心的通知在中间也可能会因为各种各样的问题到丢失,所以,一般上事务的发起方还需要实现一个消息回查的接口,当消息中心在一段时间内没有收到事务的发起方的通知的时候,消息中心会主动回查发起方,主动咨询发起方对应的事务的状态,根据主动拿到的状态来决定消息是要发送还是删除。
  • Q:系统之间在一次请求中的相互调用非常频繁,导致中间 RPC 消耗地时间比较高
  • A:合并部署。将RPC调用转化为本地jvm调用
  • Q:数据库拆分后,一个应用需要连接所有的数据库,导致数据库连接翻倍增长
  • A:单元化,在应用上层设置逻辑数据中心,进行数据分片路由,一个应用连的数据库只要和对应的逻辑数据中心的数据分片一致就可以
  • Q:1. 服务的版本升级比较费劲 2. 系统需要支撑多语言
  • A:ServiceMesh sideCar思想,在网络层进行流量拦截,使用rpc调用原始服务,sideCar对于原应用透明化

你可能感兴趣的:(ServciceMesh)