# 应用架构演进
# 单体应用
- 互联网早期，应用流量较小。只需一个应用，将所有功能代码都部署在一起
# 优点
- 可以减少成本，包括开发、部署、以及运维成本;
# 缺点
模块紧密耦合，单点容错率低
无法针对性优化，以及水平扩展
# 垂直应用
- 随着应用流量增大，依靠增加节点来处理。
- 并不是所有模块都有比较大的访问量,针对具体模块优化，产生了垂直应用
- 将原来的单体应用，拆分成几个互不相干的多个应用，提升效率.
# 优点
- 一定程度上，解决了并发问题(效率可进一步提高)。
- 可针对不同模块进行优化和水平扩展.
- 系统之间不影响，提高容错率;
# 缺点
- 系统间相互独立，无法进行相互调用（尽管可以通过技术手段解决）
- 系统间相互独立，会有重复的开发工作（尽管可以通过框架层面解决）
# 分布式架构
- 垂直的业务越多，重复的业务代码就会越多
- 将工程分为服务层，表现层两个部分
- 表现层只需处理与页面的交互（如传统的Controller控制层）,业务逻辑调用服务层实现
- 服务层中包含业务逻辑。（比如业务中台,数据中台等等）
# 优点
- 抽取公共的功能为服务层，提高代码复用性
# 缺点
- 系统间耦合度变高，调用关系错综复杂，难以维护（如服务间相互调用）;
- 如：认证中心调用消息中心、政策中心...
# SOA架构
- 随着服务的增多，容量评估、小服务资源浪费问题凸显
- 此时，需要增加一个调度中心对集群进行实时管理
- 关注的焦点在服务资源的动态管理
# 优点
- 注册中心解决服务间调用关系的自动调节
- 提供：服务调节、传输协议转换、数据格式转换、服务编制等功能
# 缺点
- 服务间会有依赖关系，一旦某个环境出错，影响较大（服务雪崩）
- 服务关系复杂，运维、测试、部署困难
# 微服务架构
- SOA的进一步发展，强调服务的彻底拆分
# 优点
- 提供相应的微服务生态
# 缺点
- 开发的技术成本高(容错、分布式事务等)
# 微服务
# 微服务带来的问题
- 这么多小服务，如何管理？
- 注册中心：服务注册、服务发现、服务剔除
- 这么多小服务，如何通信？
- restful通信
- rpc通信
- 这么多小服务，客户端如何访问它们？
- 微服务网关
- 这么多小服务，一旦出问题，如何自处理？
- 服务容错
- 这么多小服务，一旦出问题，如何排查？
- 链路追踪
# 微服务基础设施
# 服务治理
- 注册中心(
eureka1,eureka2(闭源)，zookeeper,consul,nacos) - 配置中心(
springCloudConfig,nacos)
# 服务通信
ribbon负载均衡openFeigndubbo的rpc远程调用
# 服务网关
springCloudGateway、zuul、zuul2nginx
# 服务保护
- 断路器
hystrix, - 服务防护
sentinal
# 服务链路追踪
- 链路追踪器
springCloudSleuth, - 链路分析器
zipkin
# 微服务框架
ServiceComb: 前身为华为云 的微服务引擎云服务，提供一站式的微服务开源解决方案;springCloud: 基于springBoot,整合成熟的开源服务基础设施，提供易部署、易维护的分布式系统开发工具包,致力于提供微服务开发的一站式解决方案;springCloudAlibaba: 将springCloud应用，接入阿里微服务解决方案，通过阿里中间件来搭建分布式应用系统，致力于提供微服务开发的一站式解决方案
# 微服务生态
- 敏捷开发、持续部署、持续交付(CD/CI)，
DevOps(开发运维一体化平台)理论的发展和实践 - 基于Docker等轻量级容器部署应用和服务的成熟
- k8s等云原生应用管理平台的发展和实践