微服务口水话｜青训营笔记本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动

这是我参与「第五届青训营」伴学笔记创作活动的第 21 天

本篇文章归档于 “第五届字节跳动青训营”，主要是为了完成和记录掘金的 “伴学笔记创作活动” 活动，如果你对我的其他文章感兴趣，可以去我的专栏中逛逛看有没有你想要的东西。

放在前面的话

微服务架构诞生于云原生（Cloud Native）背景之下，几乎所有的公司都在将服务上云，借这篇笔记，推荐一个不错的概念入门网站——CNCF Glossary，它是是由 CNCF（Cloud Native Computing Foundation）商业价值小组委员会 (BVS, Business Value Subcommittee) 领导的一个项目。该项目的目的是在不需要任何先决技术知识的情况下，以通俗易懂的语言阐释云原生概念。

作为中文社区的负责人之一，我强烈推荐，同时也欢迎你能参与到我们未来的建设！

微服务架构的演进之路

“架构并不是被发明出来的，而是持续演进的结果”

对于不同时代下的架构演进之路，可以参考一下《凤凰架构》，如果你想仔细了解，指路服务架构演进史。这里仅对课件内容做个记录：

单体架构：性能最高，冗余小；debug 困难，模块相互影响（非功能模块可能导致崩溃），几乎无法分工；
垂直应用架构：业务独立开发维护；不同业务存在冗余，无法复用。-> 按照业务线垂直划分
分布式架构：业务无关的模块独立服务；服务模块可能导致整个系统崩溃，调用关系复杂，不同业务依旧冗余。-> 抽出业务无关的模块
SOA 架构：服务注册；设计依旧是中心化，需要从上至下设计，重构困难。-> 面向服务
微服务架构：高效的开发迭代效率故障可控；治理、运维难度急剧增加观测挑战，安全等问题，分布式系统本身的复杂性。-> 彻底服务化

微服务的核心要素：服务治理、可观测性（日志采集、监控打点和链路追踪）和安全性（认证授权）

微服务架构的相关概念

先给整理了一些基础的概念：

服务(service)：一组具有相同逻辑的运行实体；
实例(instance)：一个服务中，每个运行实体即为一个实例；
实例与进程的关系：实例与进程之间没有必然对应关系，可以一个实例可以对应一个或多个进程(反之不常见)；
集群(cluster)：通常指服务内部的逻辑划分，包含多个实例；
常见的实例承载形式：进程、VM、k8s pod；
有状态/无状态服务：服务的实例是否存储了可持久化的数据(例如磁盘文件)。

服务注册及发现

对于单体服务，不同模块通信只是简单的函数调用；对于微服务，服务间通信意味着网络传输。在网络通信中，我们必须指定远程的 IP 地址和端口，这种硬编码的方式在微服务中显然不合适，面对如此之多的实例，肯定寻找一种方法动态实现服务间通信。

参考 DNS 的思想，引入一个中间层用于服务注册和发现，映射服务存储名与实例的关系：

下线服务：注册中心删除映射 -> 待任务结束后结束该实例；
上线服务：检查实例状态 -> 如果可用，则将注册该实例 -> 开启服务；

微服务架构弱化了连接的概念，强调请求，这意味着在外网统一网关入口情况下，内网可以用 RPC 提升性能，并且是网状调用链路，理论上服务可达所有实例。

服务治理

这种服务至上的理念极大的提高了资源利用率，但同时也带来了不少麻烦，因此，我们需要进行服务治理：

服务发现：升级服务运行新代码，采用蓝绿部署、灰度部署，以应对服务不可用、服务抖动和服务回滚；
流量治理：基于地区、集群、实例、请求等维度，对端到端流量的路由进行精确控制；
负载均衡：分配请求在每个上下游实例的分布，最大化利用资源；
稳定性治理：限流、熔断、过载保护和降低等。

Anyway，网络上的问题很多，不一定是代码逻辑的问题，需要一些妙招的方法来治理。

重试

重试可以避免偶然发生的错误，提升服务级别协议：降低错误率、降低长尾延时、容忍暂时性错误和避开下游故障实例。但它同样也会带来很多风险：

幂等性：多次请求可能会造成数据不一致；
重试风暴：随着调用深度的增加，（如果一直失败）重试次数会指数级上涨；
超时设置：超时设置得太高会降低其有效性，太低会增加延时或中断服务。

当然，这里也提供了一些重试策略：限制重试比例、防止链路重试和 Hedged Request（降低长尾延时）。

放在最后的话

微服务不等价于上云，但上云一定会采用微服务架构。这也是目前几乎所有公司的主流架构，当然，以上口水话并不能让你理解得多深，如果能有个初略的印象便是最好不过了～