这是我参与「第五届青训营 」伴学笔记创作活动的第 13 天
本文将着重介绍微服务架构背景等相关知识，侧重于背景由来、架构概览、基本要素三个方面
系统架构演变历史
-
为什么系统架构需要演进？
- 互联网的爆炸性发展
- 硬件设施的快速发展
- 需求复杂性的多样性
- 开发人员的急剧增加
- 计算机理论与技术的发展
- 单体架构 all in one process!
- 优势
- 性能最高
- 冗余小
- 劣势
- debug困难
- 模块相互影响
- 模块分工、开发流程
- 垂直应用架构 按照业务线垂直划分
- 优势
- 业务独立开发维护
- 劣势
- 不同业务存在冗余
- 每个业务还是单体
- 分布式架构 抽出业务无关的公共模块
- 优势
- 业务无关的独立服务
- 劣势
- 服务模块 bug 可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
- SOA架构 — 面向服务
- 优势
- 服务注册
- 劣势
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
- 微服务架构 — 彻底的服务化
- 优势
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
- 劣势
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
微服务架构概述
微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了 Fowler 的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。 然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。
微服务架构核心要素
1. 服务治理
2. 可观测性
3. 安全
文章总结
- 系统架构的演变历史
- 微服务架构的整体规范
- 微服务架构中的核心要素
个人总结
微服务架构述说着没有永恒的架构，只有进化的架构，但微服务架构不是银弹，也没有银弹。将现有应用迁移成微服务架构的现代化应用，不应该通过从头重写代码方式实现，相反，应该通过逐步迁移的方式。有三种策略可以考虑： 将新功能以微服务方式实现；将表现层与业务数据访问层分离；将现存模块抽取变成微服务。随着时间推移，微服务数量会增加，开发团队的弹性和效率将会大大增加。
