这是我参加[第五届青训营]伴学笔记创作活动的第九天
一.系统架构演变历史
为什么系统架构需要演进
-
互联网的爆炸性
-
发展硬件设施的快速发展
-
需求复杂性的多样化
-
开发人员的急剧增加
-
计算机理论及技术的发展
-
单体架构
all in one process,所有的服务都在一个进程里
- 优势:
- 性能最高
- 冗余小
- 劣势:
- debug 困难
- 模块相互影响
- 模块分工、开发流程
-
垂直应用架构
按照业务性垂直划分
- 优势:
- 业务独立开发维护
- 劣势:
- 不同业务存在冗余
- 每个业务还是单体
-
分布式架构
抽出业务无关的公共模块
- 优势:
- 业务无关的独立服务
- 劣势:
- 服务模块bug可导致全站瘫痪
- 调用关系复杂
- 不同服务冗余
-
SOA架构
面向服务
- 优势:
- 服务注册
- 劣势:
- 整个系统设计是中心化的
- 需要从上至下设计
- 重构困难
-
微服务架构
彻底的服务化
- 优势:
- 开发效率
- 业务独立设计
- 自下而上
- 故障隔离
- 劣势:
- 治理、运维难度
- 观测挑战
- 安全性
- 分布式系统
二.微服务架构原理及特征
-
微服务架构原理
微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的。
类上应用很多SOLID原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。
概念:把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。
定义:围绕业务领域组件来创建应用,这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能,使产品交付变得更加简单。
本质:用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
-
微服务架构特征
-
官方的定义:
- 一系列独立的服务共同组成系统
- 单独部署,跑在自己的进程中
- 每个服务为独立的业务开发
- 分布式管理
- 非常强调隔离性
- 大概的标准:
- 分布式服务组成的系统
- 按照业务,而不是技术来划分组织
- 做有生命的产品而不是项目
- 强服务个体和弱通信( Smart endpoints and dumb pipes )
- 自动化运维( DevOps )
- 高度容错性
- 快速演化和迭代