2019 Qcon(二)

第二天和第三天主要听了些中台/service mesh/混沌主题。

中台

中台解决的是重复建设的问题，将公共部分下沉。让业务与非功能性模块解藕。

2019 Qcon(二)

业务中台专注业务之间的相关性，需要组织架构的精细协作。举个例子，直播和电商两条业务线，他们共同的地方如用户模块，认证模块等，可以下沉，彼此之间低耦合。而在中台阶段将他们进行组装，拼接成完整的业务链。数据中台关注的是数据模型，这个模型是否可以应用于其他场景。从这个地方也可以看出构建中台并不是一件很容易的事情，它需要组织架构精细，需要对业务线非常熟悉而且替代性较小，架构定义清晰等。

service mesh

服务网格也是最近特别火的话题，是微服务的升级版。解决的是系统服务拆解后网络通信问题。在做微服务的时候，我们会处理一些比较基础的事情（服务注册，服务发现，负载均衡，熔断、重试）等。这些功能具有高度的重合性，每个服务都需要。相对来说学习成本也是比较高的。无论从产品业务还是从团队架构还是人力时间成本，都需要我们将这部分功能剥离出来，单独升级处理。Service mesh 为业务开发团队带来的变革：降低入门门槛，提供稳定基座，帮助团队实现技术转型。最终达到的目的是，让业务开发团队从微服务实现的具体技术细节中解放出来，回归业务。把非业务性的功能包装在sidecar中。sidecar与sidecar通信很简单，通过解析头部信息，中间数据信息传输的过程中不做加密。这样做可以加快传输速度（是不是和TCP/IP传输很相似）每个微服务通过sidecar进行消息的分发和传递，它只对sidecar感知，而对于其他微服务则是无感知的。service mesh 是以远程调用的方式让客户端接入，只要能发出请求，简单发给 servicemesh 就可以。客户端极度简化，对于典型的 rest 请求，几乎所有的语言都有完善的支持。而服务器端只要做一个事情，服务注册。这样对于多语言的支持，就变得非常舒服了。现在终于可以真正的自由选择编程语言。

2019 Qcon(二)

下图还提出了未来mesh的发展领域：db mesh，msg mesh。

2019 Qcon(二)

混沌

阿里分享了开源混沌试验脚本：https://github.com/chaosblade-io/chaosblade ，目前支持一下几个试验（网络延迟，CPU，JVM等)。根据试验我们可以测试系统的稳定性，以及服务是否能够自动降级处理等。我把代码拉下来测试了下drop service-port，确实发现iptables里面多了条DROP的规则，然后服务就不可访问了，很赞。

image.png

场景覆盖图

image.png

混沌工程的价值：

1. 人员
   验证系统的高可用性---架构师
   提升故障的应急效率---开发&运维
   提早暴露上线问题，降低故障复发率---测试
   提升用户体验---产品&设计

2. 系统
   韧性---提升系统容错，容灾能力
   基础能力---具备可监控，可恢复，可回滚
   运维高可用---提升监控运维系统的高可用性

   
   2019 Qcon(二)

2019 Qcon(二)

还有一点小tips:
项目特点决定部署模型选择：

1. 建构简单，规模巨大，优选金丝雀型；
2. 架构复杂，规模一般，优选蓝绿型；