第三时期
分布式服务架构:
当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
分布式：将一个大的应用（业务）拆分成多个子业务。（互不相干业务）部署在不同的服务器上。
解决问题
问题1：客户对页面的需求越来越高？（修改频繁）需要重新部署应用程序【每个应用都是独立的WEB应用程序】？
答：页面+业务代码（前后端分离部署）
问题2：随着业务的不断增加，模块部署在不同的服务器上。这些应用之间一定会需要业务交互？
分析：如果服务都在一台服务器上（通过JAR依赖完成调用）
现在都是部署在不同的服务器上。（服务和服务进程间调用）。
解决方案：
此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。
WebService -->Spring CXF
HttpClient/HTTP/Http RestFul
RPC
（RFC）远程过程调用协议：一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。
架构的改变必然会带来新的技术和新的问题
问题：分布式事务 分布式锁 分布Session 分布式日志
问题：
问题1：当服务越来越多，服务和服务之间调用非常混乱？（不知道对方提供哪些服务）
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现
问题2：例如商口模块访问量大部署50台服务器。支付模块访问早小，部署了10台服务器。
第四时期
流动计算架构
当服务越来越多，容量的评估，小服务资源的浪费等问题逐渐显现，此时需增加一个调度中心基于访问压力实时管理集群容量，提高集群利用率。此时，用于提高机器利用率的资源调度和治理中心(SOA)是关键。
SOA:
面向服务的架构（SOA）是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
SOA（Service Oriented Architecture）“面向服务的架构”:他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务 通常以独立的形式存在与操作系统进程中。各个服务之间 通过网络调用。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
以一个公司为例：有基层员工， 有管理层， 有老板。
最初大家都听老板指挥，谁干什么谁干什么，根据需要，你可能今天干A事情，明天干B事情，后来人越来越多了，事情也越来越多了，做事情的效率越来越低，管理也很混乱，
就开始做部门划分（服务化），专门部门做专门事情的，IT部门只做研发，人事部门只做招聘； 这个时候就无法避免的发生跨部门协作（服务器调用）， 但是你怎么知道有这样一个部门可以做这个事情呢，就要依赖行政部门（注册中心），新成立的部门要在行政哪里做一个备案（服务注册），然后公布一下，让其他部门知道了（服务发布），大家就可以在新的工作秩序里面嗨皮的上班了，这个时候依然是在公司的组织架构中运转；
分布式服务治理（解决方案） 中间件： Dubbo/SpringCloud
基于访问压力实时管理集群容量，提高集群利用率。
Dubbo 底层用的是RPC传输
SpringCloud底层用的是Http Rest 请求方式传输
总结:
微服务：
单体应用拆分成互不相干的多个小应用。每一个小的应用称为微服务。
微服务架构 = 80%的SOA服务架构思想 + 100%的组件化架构思想 + 80%的领域建模思想
SOA（面向服务架构)–>微服务架构
问题1：构建单体应用时只需要（构建项目SSM)一次即可。
现在进行服务拆分，拆分成多个小应用，而每个应用都是独立部署、独立运行。
会出现大量的重复的JAR包、配置文件、SSM整合代码）
答：SpringBoot
SpringBoot目的：就是为了简化代码的开发和项目框架的搭建过程。
架构的改变必然会带来新的技术和新的问题
SpringBoot Dubbo SpringCloud
新的问题：
分布式事务 两(二）阶段提交
分布式锁 Redis SETNX/Zookepper
分布式Session Spring Session(RedisCluster)
分布式日志 elk
优点：
1、微服务对服务的拆分变更的更细（复用性强）。
2、可根据需求使用新的技术
3、开发速度快（周期少）。适用于互联网项目。
缺点：
微服务过多，对服务的治理成本高。
服务的部署难度加大–>（Docker–>k8s)
技术难点在增加（分布式事务…)