这是我参与「第五届青训营」伴学笔记创作活动的第 10 天
零、前言
本文记录和整理了本人在跟随字节青训营学习的一些我个人感觉比较重要的内容和知识，也有一部分内容是我认为自己比较难理解或记忆的，也一并记录于此文。
撰写本文的目的主要是方便我自己的复习和查阅，倘若各位读者有与我相似的问题，也可以参考之，如果对各位有帮助那就是我莫大的荣幸，也期望各位不吝赐教，多多指出我的问题，可以在下方留言或者私信我。
一、课程目录
- 微服务架构介绍
- 微服务架构原理及特征
- 核心服务治理功能
- 字节跳动服务治理实践
二、详细知识点介绍
0. 微服务架构介绍
系统架构是什么？
系统架构是指一组组件、连接以及它们之间的关系，它们组合在一起构成一个系统，满足特定的需求和目标。系统架构的目的是提供一个清晰的视图，使系统的设计和实现更容易理解和维护。
系统架构可以应用于多种不同的领域，如软件工程、计算机系统、基础设施、业务流程等。它可以在不同的层面描述系统，如组件层面、功能层面、数据层面等。
设计合适的系统架构是一项重要的任务，它可以帮助确保系统的性能、可靠性、扩展性和安全性。它还可以帮助降低开发成本和维护成本，并且在后期开发和升级系统时提供指导。
系统架构演进的原因：
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样化
- 开发人员的急剧增加
- 计算机理论及技术的发展
演变历史过程：
微服务架构概览与核心要素：
核心要素：
- 服务治理
- 可观测性
- 安全
1. 微服务架构原理及特征
基本概念：
- 服务：一组具有相同逻辑的运行实体。
- 实例：一个服务中，每个运行实体即为一个实例。
- 实例与进程的关系：没有必然的对应关系。
- 集群：通常指服务内部的逻辑划分，包含多个实例。
- 常见的实例承载形式：进程、VM、k8s pod...
- 有状态 / 无状态服务：服务的实例是否存储了可持久化的数据。
服务间通信：
对于单体服务，不同模块通信只是简单的函数调用；
对于微服务，服务间通信意味着网络传输。
服务注册及发现：
Q：在代码层面，如何指定调用一个目标服务的地址(ip:port)？
A：新增一个统一的服务注册中心，用于存储服务名到服务实例的映射，与DNS类似，引入一个中间层。
在代码层面指定目标服务的地址（IP:端口）的方法因语言和使用的网络协议而异：
- 在使用 HTTP 的语言中，可以在请求 URL 中指定 IP 和端口。例如，使用 Python 的 requests 库：
javaCopy codeimport requests response = requests.get("http://<IP>:<PORT>/<endpoint>")
- 在使用 gRPC 的语言中，可以通过创建一个 gRPC 客户端实例时传递地址参数。例如，使用 Python 的 grpcio 库：
javascriptCopy codeimport grpc from <proto file import> import <service name>Stub channel = grpc.insecure_channel("<IP>:<PORT>") stub = <service name>Stub(channel)
- 在使用其他协议的语言中，也可以使用与语言相关的特定函数或库来连接到目标服务。
请注意，还可以使用 DNS 解析将主机名映射到 IP 地址，以避免在代码中硬编码 IP 地址。
流量特征：
- 统一网关入口
- 内网通信多数采用PRC
- 网状调用链路
从流量角度看微服务架构的方法有以下几种：
- 流量监控：通过实时监控请求和响应数据来了解微服务之间的通信情况，包括请求数量、响应时间、错误率等。
- 流量分析：通过分析请求和响应数据来识别和了解微服务之间的流量关系，包括请求路径、请求频率、数据传输量等。
- 流量分配：通过调整请求分配策略来优化微服务的负载均衡，确保系统的可用性和稳定性。
- 流量访问控制：通过实施流量访问控制策略来保护微服务免受恶意请求的攻击，包括限流、黑白名单等。
2. 核心服务治理功能
服务发布：
难点：
- 服务不可用
- 服务抖动
- 服务回滚
蓝绿部署：
蓝绿部署是一种持续交付和部署方法，旨在在生产环境中提供更稳定和安全的部署过程。
具体而言，蓝绿部署通过同时维护两个生产环境（蓝环境和绿环境），在每次部署前先将新版本部署到绿环境，并对其进行测试和验证，确保其符合要求后再将其切换到蓝环境。如果在绿环境发现了问题，可以立即回滚，而不影响正常的生产环境。
蓝绿部署的优势包括：
- 提高可用性：通过保证生产环境始终有一个稳定的版本，可以提高系统的可用性。
- 降低风险：通过在绿环境中先验证新版本，可以降低因部署问题导致生产环境不稳定的风险。
- 提高效率：通过快速回滚等机制，可以提高部署的效率和效果。
金丝雀发布：
金丝雀发布是一种持续交付和部署方法，旨在通过小规模的实验来评估新版本的影响和风险。
具体而言，金丝雀发布通过在生产环境中小规模地部署新版本，以便在生产环境中评估新版本的影响，并通过监控和诊断工具来验证新版本是否正常工作。如果新版本发现了问题，可以立即回滚。
金丝雀发布的优势包括：
- 提高效率：通过小规模的部署，可以更快地评估新版本的影响。
- 降低风险：通过在生产环境中评估新版本，可以降低因部署问题导致生产环境不稳定的风险。
- 提高效果：通过小规模的试验，可以更好地了解新版本的表现。
流量治理：
在微服务架构下，我们可以基于地区、集群、实例、请求等维度，对端到端流量的路由路径进行精确控制。
负载均衡Load Balance：
负载均衡，可以帮助提高网络系统的可用性、稳定性和可配置性。
负载均衡负责分配请求在每个下游实例上的分布。
具体来说：负载均衡是一种用于分配网络请求的技术，旨在通过平均分配请求流量，以避免单个服务器或终结点的过载。
具体而言，负载均衡通过使用代理服务器或硬件负载均衡器来分配请求，使得请求能够更平均地分配到多个服务器或终结点上。这样，单个服务器或终结点就不会因为大量请求而瘫痪，从而提高整体系统的可用性和稳定性。
负载均衡还可以通过支持多种负载均衡策略，例如轮询、加权轮询和最小连接数策略等，以提高系统的灵活性和可配置性。
稳定性治理：
微服务架构中典型的稳定性治理功能：
- 限流
- 熔断
- 过载保护
- 降级
3. 字节跳动服务治理实战
可以直接参考：字节跳动微服务架构体系演进架构字节跳动技术团队_InfoQ精选文章
三、课后习题
Q：
- 结合 CAP 等原理，思考微服务架构有哪些缺陷？
- 微服务是否拆分得越“微”越好？为什么？
- Service Mesh 这一架构是为了解决微服务架构的什么问题？
- 有没有可能有这样一种架构，从开发上线运维体验上是微服务，但实际运行又类似单体服务
A：
-
微服务架构的缺陷可能包括：
- 复杂度增加：随着微服务数量的增加，整个系统的复杂度和管理成本也会增加。
- 分布式数据一致性问题：在分布式环境中维护数据一致性是很困难的。
- 服务发现和注册问题：服务的发现和注册可能很复杂。
- 难以调试和监控：由于微服务间的交互很复杂，因此难以调试和监控整个系统。
- 测试困难：在微服务环境中测试是困难的。
-
微服务没有单一的答案，但不是拆分得越微越好。微服务的分解要考虑到业务需求，代码耦合度和维护难度等因素。
-
Service Mesh 是为了解决微服务架构中的管理和控制问题而诞生的。它主要解决了微服务间的通信、负载均衡、错误处理等问题，从而简化了微服务环境的管理和控制。
-
可能有。例如，微服务可以用于提高研发效率和生产效率，但实际运行时却可以通过缓存和本地调用等方式以类似单体服务的方式工作。
未完待续...（随时补充修改）
谢谢大家的阅读，欢迎互动，也欢迎访问我的博客！
