AI TALK | 云原生时代的微服务架构与关键技术_ai 微服务

随着云原生与微服务技术的逐步发展，业界也逐步构建出一整套比较完整的微服务技术体系。

面向云原生时代，微服务架构是从业人员绕不开的一个话题，腾讯云AI&腾讯优图的内容风控安全审核能力也与微服务技术息息相关。

本文总结了业内最新的技术沉淀，从相对宏观的角度去讲述微服务的问题域与挑战点，并深入细节讲述一些微服务关键技术，包括微服务拆分微服务间通信机制，分布式事务微服务，可观测安全性等。

目前微服务还在不断发展中，有很多技术还未发展到成熟阶段，希望本文能够帮助大家拥有基本的了解。

01.什么是云原生

上图是CNCF对云原生的定义，从字面意义上来讲，cloud native就等于cloud+native。简单来说，云原生代表着因云而生。它主要包含以下方面：

02.微服务架构的优缺点：没有银弹

(1)问题的产生背景：

1)单体架构本身并无错

①适合于项目早期阶段，应用简单、规模小。

②开发、测试、部署、运维简单

③横向扩展简单但随着时间推移，功能越来越复杂、开发团队越来越大，开发、测试、部署、扩展变得更加困难。

2)单体地狱的到来

①系统变得庞大而复杂，开发者望而生畏

②开发速度缓慢

③CICD变成遥不可及

④扩展困难

⑤高可用交付困难

⑥历史包袱重，不得不面对过时的技术栈

(2)具体来说：

1)通常，在设计阶段要设计 10 到 100 倍左右的逻辑容量，因为在后期修改设计会带来很高的难度，所以要提前设计好冗余容量。

2)在实现阶段，通常要按照 5 到 10 倍左右的容量进行实现，实现阶段需要付出一定的成本，没有必要为非常长远的将来实现，可以随业务的进展而逐步实现设计时最大容量。

3)部署阶段，以 2 到 5 倍的容量进行部署，可以应付一段时间内的容量增长。

4)但如果是预期的增长非常大，就要采用更加灵活的云部署手段，并为突发峰值做好预案准备。

(3)"银弹"来源 ？

在欧洲中世纪的传说中，有一种叫“人狼”的妖怪，就是人面狼身。它们会讲人话，专在月圆之夜去袭击人类。而且传说中对“人狼”用一般的枪弹是不起作用的，普通子弹都伤不到也打不死它，只有一种用银子做成的特殊子弹才能把它杀死。

Brooks在他最著名的随笔文章《No Silver Bullet》里引用了这个典故 ，说明在软件开发过程里是没有万能的终杀性武器的，只有各种方法综合运用，才是解决之道。而各种声称如何如何神奇的理论或方法，都不是能杀死“软件危机”这头人狼的银弹。他当时大胆声称并预言方法学家们10年之内绝找不到什么好的的神奇银弹。他的文章发表后，被广泛引用，后来他的随笔结集成书，《人月神话》。

从此，在软件界，银弹（Silver Bullet）成了一个通用的比拟流行开来。1975年所出版的《人月神话》—被称为软件工程圣经。

(4)微服务的特性与优缺点

1)微服务的两个关键特性

①微服务之间松耦合，仅通过API进行通信

②每个微服务都有自己独立的数据库

2)微服务的优点

①使得大型复杂持续可以持续交付持续部署

②每个服务都相对较小并且易于维护

③服务可以独立部署

④服务可以独立扩展

⑤微服务架构可以实现团队的独立自治

⑥更容易实验和采纳新技术

⑦更好的容错性

3)微服务的缺点

①服务拆分和定义是一项挑战

②分布式系统带来的复杂性，使得开发、测试、部署变得更加困难

③当部署跨越多个服务的功能时，需要谨慎的协调更多的开发团队

④开发者需要思考在什么阶段使用微服务

03.如何拆分单体服务：领域驱动设计大放异彩

(1)什么是领域驱动？

Eric Evans于2003年提出的。主要解决随着业务越来越复杂，大量的逻辑堆积在一个巨型类中的例子屡见不鲜，代码的复用性和扩展性无法得到保证。DDD是一套前人总结出来的模式，用于解决上述的业务问题。

(2)领域驱动设计是如何解决上述问题的？

1)第一步考虑把需求分解成一个一个子问题域。

2)第二步把每个子问题域分解成一个一个聚合对象，应用程序通过各种子问题域之间的编排与协作，从而实现复杂的业务逻辑满足业务需求。

3)DDD是解决复杂中大型软件的一套行之有效方式，在微服务领域已成为主流技术。

(3)DDD的标准使用姿势

1)产品需求与愿景对产品的顶层价值设计，对产品目标用户、核心价值、差异化竞争点等战略层信息达成一致，避免产品在演进过程中偏离方向。

参与角⾊：业务需求方、产品经理、开发

2)用户旅程分析针对核心用户及顶层服务的一种定性分析，从⽤户视角出发，探索问题域中的典型场景分析。同时也是从用户视角对问题域的探索，产出问题域中需要支撑的场景分类及典型场景，用以支撑领域建模阶段。

参与角色：产品经理、开发、测试

3)领域建模通过对业务和问题域进⾏分析，建⽴领域模型，向上通过限界上下⽂指导微服务的边界设计，向下通过聚合指导实体的对象设计。领域建模主要采用事件风暴方法。

参与角色：领域专家、架构师、产品经理、开发和测试

4)微服务Map整个产品服务架构的体现。结合业务与技术因素，对服务的粒度、边界划分、集成