为什么需要分布式系统？
随着业务体量增大，系统复杂程度增加，单体架构是无法满足公司级别业务需要的。为了更好的增大系统容量，需要分布式架构来冗余系统，既可以很好的利用多台机器，承载高并发请求，又可以避免单点故障，增强系统可用性。 这里，给出分布式架构和单体架构的对比。【可以从自己做的项目出发，思考如果一个项目需要成败上千人一同完成，应该如何保证系统的可用性以及开发的敏捷性？（分布式架构 -> 微服务）】
总体来看，分布式采用架构治理的复杂性代替了业务开发复杂性。 分布式系统架构的难点在于系统设计，以及管理和运维。
分布式系统的发展历程
-
20世纪90年代，单体架构，软件模块高度耦合
-
2000年左右，松耦合SOA(基于服务的架构)架构，需要标准的协议或中间件来联动其他相关联的服务（如ESB Enterprise Service Bus 企业服务总线），这样服务间并不直接依赖。
- SOA架构可以被看成 IoC（控制反转）和 DIP（依赖倒置原则）设计思想在架构中的实践
-
2010年左右，微服务架构，服务间的整合需要一个服务编排或服务整合的引擎。
- 微服务的出现使得开发速度变得更快，部署快，隔离性高，系统的扩展度也很好，但是在集成测试、运维和服务管理等方面就比较麻烦。
从单体架构到分布式系统开发，业务难点？
-
异构系统的不标准问题
- 不同的软件，不同的语言会出现不同的兼容性和不同的开发、测试、运维标准。不同的标准会让我们用不同的方式来开发和运维，引起架构复杂度的提升。
- 要有相同的规范标准
-
系统架构中的服务依赖性问题
-
如果非关键业务被关键业务所依赖，会导致非关键业务变成一个关键业务。
-
服务依赖链中，出现“木桶短板效应”——整个 SLA 由最差的那个服务所决定。
- SLA：Service-Level Agreement的缩写，意思是服务等级协议。 服务级别协议是指提供服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。
-
-
故障发生的概率更大
- 出现故障不可怕，故障恢复时间过长才可怕。
- 出现故障不可怕，故障影响面过大才可怕。
- 在设计时就要考虑如何减轻故障，如果无法避免，也要使用自动化的方式恢复故障，减少故障影响面。
-
多层架构的运维复杂度更大
- 系统一般可以分为四层：基础层、平台层、应用层和接入层
- 基础层就是机器、网络和存储设备等
- 平台层就是中间件层，Tomcat、MySQL、Redis、Kafka之类的软件
- 应用层就是业务软件，各种功能的服务
- 接入层就是接入用户请求的网关、负载均衡或是CDN、DNS等
分布式系统的关键技术
-
分布式系统需要做的事
- 提高整体架构的吞吐量，服务更多的并发和流量
- 提高系统的稳定性，让系统的可用性更高
分布式系统的关键技术：
-
服务治理
- 服务拆分、服务调用、服务发现、服务依赖、服务的关键度定义……服务治理的最大意义是需要把服务间的依赖关系、服务调用链，以及关键的服务给梳理出来，并对这些服务进行性能和可用性方面的管理。
-
架构软件管理
- 服务之间有依赖，而且有兼容性问题，所以，整体服务所形成的架构需要有架构版本管理、整体架构的生命周期管理，以及对服务的编排、聚合、事务处理等服务调度功能。
-
DevOps
- dev + ops
- DevOps 旨在实现既快又稳的工作流程，使每个想法（比如一个新的软件功能，一个功能增强请求或者一个 bug 修复）在从开发到生产环境部署的整个流程中，都能不断地为用户带来价值
- 分布式系统需要 DevOps 的全流程，其中包括环境构建、持续集成、持续部署
-
自动化运维
- 对服务进行自动伸缩、故障迁移、配置管理、状态管理等一系列的自动化运维技术
-
资源管理调度
- 应用层的自动化运维需要基础层的调度支持，也就是云计算 IaaS 层的计算、存储、网络等资源调度、隔离和管理。
-
整体架构监控
- 对三层系统（应用层、中间件层、基础层）进行监控。
-
流量控制
- 负载均衡、服务路由、熔断、降级、限流等和流量相关的调度都会在这里，包括灰度发布之类的功能也在这里。
-
...
参考：《左耳听风》---- 分布式架构
