这是我参与「第五届青训营 」笔记创作活动的第4天
本篇介绍了在大多数互联网公司的标准架构——微服务架构。大多数互联网公司在生产环境中大多使用微服务架构，而这在学校中可能不太受到重视。
前置回顾
微服务架构是让每一个服务单元所负责的工作更加细化，每一个服务单元只负责整体接口的一小部分。以蛋糕店来说，微服务架构是将以前的“每一个蛋糕师独立完成制坯、烘焙、打包工作”变成“有独立的制坯师、烘焙工、打包机、调度系统”的细化架构。前面的那种独立模式可称为单机模式，从单机模式到微服务模式的演变过程中，还发展出了若干种过渡模式，例如 SOA 架构 分布式架构 垂直应用架构。
以实际应用来说，微服务是将传统 Java Web 项目中的 Controller Service 都独立拆分成一个个服务，最后利用某种调度系统令数据在微服务之间流动，最后输出结果。
在微服务架构中，微服务系统与网关之间采用 HTTP 通讯。在微服务系统内部，为了减少延迟和提高性能，通常采用 RPC 调用的方式通讯。
在传统单机模式中，虽然运行效率高，易于部署，但是其 Debug 和迭代效率差。在微服务系统中，由于服务的更新是以模块为单位进行的，所以开发迭代效率很高， Debug 也较为简单，同时还能避免单机模式中异常故障沿着函数调用链传播的问题。总体来说，微服务架构的出现是为了适应互联网流量的飞速增长。
微服务架构：从上到下分为网关 微服务层 基础设施层。微服务在系统内部是网状调用。
微服务架构核心要素
- 服务治理： 服务注册 服务发现 负载均衡 扩缩容 流量治理 稳定性治理
- 可观测性： 日志分析 日志采集 监控打点 监控大盘 异常报警 链路追踪
- 安全： 身份验证 认证授权 访问令牌 审计 传输加密 黑产攻击
服务的注册和发现
在传统单机模式中，一个函数就代表了一个微服务。想要调用一个服务，直接在代码中指定函数即可。但是，在微服务架构中，有数百上千个相同的动态的服务提供者。为了能够实现负载均衡和动态扩缩容等功能，我们不能在代码中硬编码微服务的地址。而是应该采取某种列表和算法，在运行过程中动态选择将要调用的服务。
为什么不使用 DNS 作为动态服务选择器？
- 本地 DNS 存在缓存，会导致微服务的更新存在延时。对动态扩缩容支持不佳。
- 本地 DNS 不存在负载均衡算法
- 本地 DNS 不能返回端口
虽然 DNS 不能作为服务提供器在微服务架构中使用，但是我们可以借鉴 DNS 的思想来设计一个服务提供器。微服务在需要调用其他微服务时，动态查询服务提供器，服务提供器在评判各个注册在服务器中的微服务实例的情况后返回一台微服务实例，微服务再去调用这台实例。这样就实现了服务的动态分发。
服务提供器还能提供服务上下线的功能。当管理员需要上下线某个微服务实例时，为了避免直接下线导致流量失败，可以先去服务提供器中删除这些需要操作的服务器，等到服务器实例中流量处理完成后再进行服务的上下线。服务提供器还能实现微服务的健康检查功能。
思考：微服务架构将单元更加细化，使得每个单元能够承载更多流量，从而满足互联网流量持续增长的需求。微服务的管理策略和超级计算机中对每个节点的管理策略有相似之处。
