第五章 九析带你轻松完爆 service mesh - istio 前世

系列文章:

总目录索引：九析带你轻松完爆 istio 服务网格系列教程

目录

1 前言

2 架构演变史

    2.1 单体架构

    2.2 垂直架构

    2.3 微服务架构

3 微服务架构模型演进史

    3.1 框架与通信

    3.2 运行时的支撑服务

    3.3 服务安全

    3.4 服务监控和告警

    3.5 服务部署

    3.6 底层服务

    3.7 服务防护

    3.8 全链路压测

4 微服务架构模型全景图

5 带来的问题

    5.1 服务治理方式不统一

    5.2 重复造轮子

    5.3 服务治理缺乏标准化

6 总结

---

1 前言

        介绍 istio 之前，要先讲微服务，因为 istio 是在微服务技术体系上发展起来的。当你对微服务的技术体系有了一定把握之后，回过头再来理解 istio，你就会感觉技术果然是一路传承向前发展的。

历史总会反复，但科技永远向前。

        本文很多内容来自我在多个公司的技术分享后的 ppt 截图，如果你对此 ppt 感兴趣，可以向我索要。

---

2 架构演变史

2.1 单体架构

特点：

1 所有功能集成在一个项目工程中

2 所有功能打包在一个 web 包部署到服务器

3 应用跟数据库分开部署

4 通过部署应用集群和数据库集群来提高系统性能

优点：

架构简单，前期开发成本低，周期短。小型项目首选。

缺点:

1 全部功能集成在一个工程中，对于大型项目不易开发、扩展和维护

2 系统性能扩展只能通过扩展集群，成本高

3 技术栈受限

2.2 垂直架构

特点：

当访问量逐渐增大，单一应用增加机器带来的性价比越来越小，将应用拆成互不相关的几个应用，以提升效率。

优点：

1 相关架构简单，前期开发成本低，周期短，小型项目的首选

2 通过垂直拆分，原来的单体不至于无限扩大

3 不同的项目可采用不同的技术栈

缺点：

1 同业务域功能集成在一个工程中，对于大型项目不易开发、扩展和维护成本高

2 系统性能扩展只能通过扩展集群，成本高，有瓶颈

3 单体之间的函数调用过度到系统之间的 rpc 或者 http 调用，服务发现需要单独机制保证

2.3 微服务架构

特点：

1 将系统服务层完全独立出来，并将服务层抽取为一个个微服务

2 微服务遵循单一原则

3 微服务之间采用 RESTful轻量级协议进行传输

优点：

1 服务拆分粒度更细，有利于资源重复利用，提高开发效率

2 可以更加精准指定每个服务的优化方案，提高系统的可维护性

3 微服务架构采用去中心化思想，服务之间采用 RESTful 等轻量级协议通信，相比 ESB 更轻

4 适合互联网产品，产品迭代更加快速和便捷

缺点：

1 微服务过多，服务治理成本高，不利于系统维护

2 分布式系统开发的技术成本高（容错、分布式事务等），对团队技术挑战大

---

3 微服务架构模型演进史

        微服务架构的模型也是一个从简单到复杂的演进过程。

3.1 框架与通信

        微服务架构初期，主要的技术诉求是寻找更简单和轻量的开发框架，不同的开发框架意味着采用不同的通信协议。

3.2 运行时的支撑服务

        当服务的编写和通信解决了之后，接下来就要考虑一些运行时的支撑服务了。这些服务跟业务去耦，属于基础层的支撑服务，比如网关、负载均衡、服务注册与发现、配置中心等。

3.3 服务安全

        解决了服务的通信以及基础支撑后，大体上业务就可以开展了。但是这样裸奔的服务是有很大安全风险的，很多敏感的信息在不经过认证和授权就可以轻易获取到，因此服务安全就加入到了微服务的模型体系中。服务安全主要有两种，分别是 jwt 和 oauth2。

3.4 服务监控和告警

        服务在解决了通信、支撑和安全之后，就可以愉快地展开工作了。但就跟判断健康需要做体检一样，判断在线服务是否健康就需要监控和遥测，当工作负载超过了阈值就要告警通知人为介入。服务的监控有很多的维度，常见地有系统指标监控、业务指标监控、服务健康检查、调用链监控、日志监控等。

3.5 服务部署

        容器化时代带来了新的运维思路，原有基于虚拟机、物理机的重运维开始向基于容器以及容器编排的轻运维转换，这种转换也带来了服务部署方式的改变。更快、更好、更有效的部署成为微服务架构模型新的挑战。

        服务部署需要解决的问题有发布机制的引入、镜像治理、容器治理、卷管理、CI/CD 等方面。

3.6 底层服务

        当业务范围越来越广，再大的公司也不可能解决任何技术问题，这时就需要引入一些业界优秀的第三方服务作为底层服务来解决特定问题。有时这些第三方服务并不可能完全适合自己的架构，因此就需要做适当的剪裁。尽管如此，这些第三方服务也构成了整个微服务架构模型中不可或缺的一部分。常用的第三方底层服务有分布式消息中间件、分布式数据访问、分布式任务调度和分布式缓存等。底层服务跟基础支撑服务的区别在于前者更多在业务问题域，而后者则主要是通用问题域。

3.7 服务防护

        就像胃口再好的人也不可能一次吃下整头大象一样，编写再好的服务也不可能支持无限的请求。技术人员在处理无限、不可期技术场景的技术方案时，经常的策略是以不变应万变：根据目前的服务负载设置峰值，超过峰值就进行熔断、限流等措施。

        熔断如下图所示：

        降级如下图所示：

        限流如下图所示：

3.8 全链路压测

        在上面的介绍中，我们介绍了微服务架构模型的各个维度。本来可以在这里结束，但是想想实在不妥，因为我们缺少了很关键的一环，那便是测试。

        全链路压测是稍具规模的科技公司都必须要做的工作之一。它的重要性不言而喻，当业务发展超出预期，系统要具有先知先觉的能力以抵御洪灾。毕竟未雨绸缪总好过亡羊补牢。全链路压测是一个大的话题，因为这里介绍的是 istio，故这里一笔带过，有关 ppt 详情我也照顾篇幅不再赘述，如果有朋友对此感兴趣，可以向我索要。

---

4 微服务架构模型全景图

        下图展示了整个微服务架构模型：

---

5 带来的问题

        微服务架构的引入带来了很多好处，但同时也带来了服务治理诸多的问题。核心问题如下：

5.1 服务治理方式不统一

        不同服务治理的方式会引入不同的中间件，而这些中间件的技术标准和维护标准都不同。因此运维人员或者架构人员必须掌握每种中间件的使用方法，很多时候这对一个人力资源有限的科技公司并不现实。

5.2 重复造轮子

        微服务架构是允许多语言栈、多技术栈的，但不同的技术栈针对通信、支撑服务、服务安全、服务监控、熔断/降级/限流等通用技术问题却需要各自的解决方案，实在是成本的浪费。

5.3 服务治理缺乏标准化

        由于服务治理缺乏标准化，因此微服务治理的好坏全依靠技术人员个人的能力、经验和水平，这就有点像手工作坊时代，器物优质全靠工匠。但是无标准化显然不符合科技发展的轨迹。

---

6 总结

        微服务发展目前已经趋于稳定，并成为了技术主流，但与此同时它的处境却越来越尴尬，暴露的问题也越来越尖锐。幸运的是，服务网格时代到来了，服务网格的领军 istio 正稳步进入历史舞台，并变得越来越炙手可热。下文九析将继续带你轻松完爆 istio。