1 微服务架构演变过程之传统架构
微服务架构如何演变的？
传统单体架构→分布式架构→SOA面向服务架构→微服务架构模式→服务网格技术？
传统单体架构模式
传统的单体架构，也就是单点应用，也就是早期的SSM或者SSH整合项目。
采用分层架构模式、数据库访问层、业务逻辑层、控制层，从前端到后端所有的代码都是一个人写的。
com.chenyun.controler —springmvc 视图层 jsp/ftl
com.chenyun.service —业务逻辑层
com.chenyun.dao—数据库访问层
将项目的代码都放入到同一个项目，部署在同一个tomcat中。
优点：开发简单、运维简单
缺点：该架构模式没有对业务逻辑实现拆分，所有的代码都写入到同一个项目中，只适合小团队或者个人形式开发，不适合团队模式协同工作开发；
如果系统中某个模块出现了不可用的情况下，会导致整个系统无法使用。
应用场景：政府项目、管理系统、crm、oa 适合于个人小团队开发。
2 微服务架构演变过程之分布式架构
分布式架构模式
分布式的架构模式基于传统的架构模式演变过来，将传统的单点系统实现根据业务拆分。会拆分为会员系统、订单系统、支付系统、秒杀系统等，从而降低整个项目的耦合度，这种架构模式开始慢慢适合于互联网公司团队开发。
会员系统 member.chenyun.com
支付系统 pay.chenyun.com
命名为系统：包含服务和视图层。
4 微服务架构演变过程之SOA面向服务架构
SOA面向服务架构模式
SOA面向服务架构就是基于分布式架构模式演变过来，俗称服务化，也就是面向于接口开发（服务开发）。将共同存在业务逻辑抽取成一个公共的服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。
能够解决什么问题：代码冗余性问题。
服务：只是有接口，没有控制层，没有视图层
com.chenyun.service
com.chenyun.dao
SOA架构模式特点：
SOA架构模式传输协议采用SOAP协议（Http/Https+XML）实现传输，在高并发情况下实现通讯该协议存在大量的冗余性传输，而且非常占用带宽，所以在后来微服务架构中使用json替代了xml。
SOA架构模式实现方案：WebService或者ESB企业服务总线，底层采用SOAP协议传输。
传统政府、银行项目还是保留的在使用WebSercice，互联网公司肯定采用http+json形式实现传输。
3 微服务架构演变过程之SOA面向服务架构
SOA面向服务架构模式
SOA面向服务架构就是基于分布式架构模式演变过来，俗称服务化，也就是面向于接口开发（服务开发）。将共同存在业务逻辑抽取成一个公共的服务，提供给其他接口实现调用，服务与服务之间采用rpc远程调用技术。
能够解决什么问题：代码冗余性问题。
服务：只是有接口，没有控制层，没有视图层
com.chenyun.service
com.chenyun.dao
SOA架构模式特点：
SOA架构模式传输协议采用SOAP协议（Http/Https+XML）实现传输，在高并发情况下实现通讯该协议存在大量的冗余性传输，而且非常占用带宽，所以在后来微服务架构中使用json替代了xml。
SOA架构模式实现方案：WebService或者ESB企业服务总线，底层采用SOAP协议传输。
传统政府、银行项目还是保留的在使用WebSercice，互联网公司肯定采用http+json形式实现传输。
4 SOA架构模式存在哪些缺点
SOA架构模式存在哪些缺点：
- 采用SOAP协议实现通讯，xml传输非常重，效率比较低；
- 服务化管理和治理设施不够完善；
- 依赖于中心服务发现机制；
- 不适合于前后分离架构模式；
5 微服务架构演变过程之微服务架构模式
微服务架构模式的基本概念
微服务架构模式就是从soa架构模式演变过来的，比SOA架构模式对服务拆分粒度会更加精细，采用前后端分离的架构模式，让专业的人去做专业的事情，可以实现高效率开发。
微服务架构中，每个服务之间都是互不影响，每个服务必须要独立部署、运维、互不影响，微服务架构模式非常轻巧、轻量级，适合于互联网公司开发模式。
服务与服务之间通讯的协议采用restful形式，数据交换格式采用Http+Json格式实现传输。整个传输过程中采用二进制，所以Http协议可以实现跨语言的传输，并且和其他语言实现通讯，所以开放平台一般都是采用Http+Json格式传输。
6 微服务架构与SOA架构模式实现区别
1通讯协议
微服务架构基于SOA架构模式演变过来，继承SOA架构优点，在微服务架构中去除了SOA架构中SOAP协议和ESB企业服务总线，改为Http+JSON形式传输接口。
ESB企业服务总线：解决多系统之间跨语言无法实现通讯的问题，对数据协议实现转换，可以提供可靠的消息传输，通过第三方框架实现。
一般情况下都是采用Http+JSON格式传输，所以没有必要使用ESB企业服务总线。
2服务拆分粒度
微服务架构模式比SOA架构模式粒度更加精细，提倡让专业的人去做专业的事情，目的是实现高效率的开发，每个服务与服务之间都互不影响，每个服务都是独立数据库、Redis连接、MQ等，并且都是实现独立部署，整个服务架构更加轻巧、轻量级。
在SOA架构中，有可能存在多个服务共享同一个数据库，微服务架构更加强调每个服务都是独立数据库部署，互不影响。
3迭代
微服务的架构模式比SOA架构模式更适合于互联网公司敏捷、高效、快速迭代版本开发，因为粒度非常精细。
7 微服务架构中会存在哪些问题
分布式事务解决方案（rabbitmq、rocketmq事务消息、lcn（淘汰）、seata） 最终一致性概念。
分布式任务调度平台（XXL-Job、AlibabaCloud Scheduler、elastic-job）
分布式服务注册与发现（eureka、consul、zookeeper、Nacos）
分布式日志采集系统elk+kafka
分布式服务追踪与调用链系统 Zipkin
分布式服务配置中心 (springcloud config/携程阿波罗/nacos/disconfig)
微服务中非常重要的概念：独立部署、可配置、动态化。
8 什么情况下公司会采用SpringCloud
为什么要使用到SpringCloud
SpringCloud并不是一个rpc远程调用框架，而是一个微服务全家桶的解决方案的框架。
理念就是一条龙服务解决我们在微服务架构中遇到的问题。
服务治理：eureka
分布式配置中心：SpringCloud config
客户端调用工具：rest/feign客户端 rpc远程调用
Rpc远程调用框架有哪些？
Httpclient、dubbo、feign、grpc、基于netty手写rpc
阿里巴巴、腾讯、百度等一些比较大型互联网公司中，整个公司内部实现rpc通讯的框架、服务治理都是内部自己研发，SpringCloud适合公司有一定规模但不是特别有钱，中小型。
9 SpringCloud第一代与第二代的区别
SpringCloud第一代实际上都是用的Netflix开源的组件整合微服务解决方案。
SpringCloud第二代实际就是自己研发和国内优秀的微服务解决框架实现整合。
SpringCloud第一代：
SpringCloud Config 分布式配置中心
SpringCloud Netflix 核心组件
Eureka:服务治理
Hystrix:服务保护框架
Ribbon:客户端负载均衡器
Feign：基于ribbon和hystrix的声明式服务调用组件
Zuul: 网关组件,提供智能路由、访问过滤等功能。
SpringCloud第二代（自己研发）和优秀的组件组合：
Spring Cloud Gateway 网关
Spring Cloud Loadbalancer 客户端负载均衡器
Spring Cloud r4j(Resilience4J) 服务保护
Spring Cloud Alibaba Nacos 服务注册
Spring Cloud Alibaba Nacos 分布式配置中心
Spring Cloud Alibaba Sentinel服务保护
SpringCloud Alibaba Seata分布式事务解决框架
Alibaba Cloud OSS 阿里云存储
Alibaba Cloud SchedulerX 分布式任务调度平台
Alibaba Cloud SMS 分布式短信系统
