JEE架构
JEE将企业级软件架构分为三个层级：Web层、业务逻辑层、数据存取层，将80%通用的与业务无关的逻辑和流程封装在应用服务器的模块化组件中。
遇到的问题：
- 所有模块化组件混合运行在同一服务中
- 可对多个模块化组件的整体JVM进程进行水平扩展，无法对某个模块化组件水平扩展
- 某个模块化组件上线需要对所有的模块化组件一起上线
- 模块依赖不清晰、互相耦合成家常便饭。
服务化架构（SOA，WebService、ESB）
为解决单体架构的瓶颈，SOA出现，，将模块化组件进一步划分形成独立的对外服务的网络化组件，每个网络化组件通过某种网络协议对外提供服务：
- 定义良好的接口，通过网络协议对外提供服务，松耦合，可灵活编排和组装
- 服务内部实现改变是不影响整个流程对外提供服务
- 定义标准接口让底层通用服务下沉，供多个上层的使用方同时使用。
- 让企业最大化的使用内部和外部的公共服务，避免重复造轮子
WebService
使运行在不同的机器及操作系统上的服务互相发现和调用成为可能，并且通过某种协议交换数据
WebService工作原理：
- 服务提供者2和3通过UDDI协议将服务注册到WebService目录服务中
- 服务消费者1通过UDDI协议从WebService目录中查询服务，获取服务的WSDL服务描述文件
- 服务消费者1通过WSDL语言远程调用和消费2和3提供的服务
问题：
- 依赖中心化的服务发现机制
- 通信协议太重
- 服务化管理和治理设施并不完善
ESB
ESB企业服务总线的简称，是用于设计和实现网络化服务交互和通信的软件模型，用于企业信息化系统集成服务场景中。没有中心化的服务节点，每个服务提供者都是通过总线的模式插入系统
ESB的核心在于企业服务总线的功能和职责：
- 监控和控制服务之间的消息路由
- 控制可插拨的服务化的功能和版本
- 解析服务之间交互和通信的内容和格式
- 通过组合服务、资源和消息处理器来统一编排业务需要的信息处理流程
- 使用冗余来提供服务备份能力
问题：
- 更多体现了系统集成的便利性，将服务组合在一起，并提供组合的业务流程服务
- 组合在ESB上的服务本身可能是一个过重的整体服务，或者是传统的JEE服务
- ESB视图通过总线来隐藏系统内部的复杂性，但是系统内部的复杂性仍然存在
- 对于总线本身的中心化的管理模型，系统变更影响的范围经常会随之扩大
微服务
可独立开发、配置、运行和可维护的自服务，致力于松耦合和高内聚的效果，不再强调服务总线和通信机制多样性，通过Restful的API和轻量级的消息通信协议来完成。并不是为了拆分而拆分，目的是实现水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做专业事，
特点：
- 把每个职责单一的功能放到独立服务中
- 每个服务单独一个线程
- 每个服务多实例运行，达到平滑伸缩
- 独立数据存储
- 独立运营平台
- 独立水平伸缩
与单体架构对比
微服务架构更灵活并且可水平伸缩，让专业人做专业事
与SOA服务化对比
目的不同
- SOA服务化范围更广，强调不同的异构服务间的协作和契约，强调有效集成、业务流程编排
- 微服务在于有效拆解应用，实现敏捷部署和开发，减少跨团队沟通，让专业人做专业事，缩小变更和迭代影响的范围，并达到单一服务更容易水平扩展的目的
部署方式不同
- 微服务将应用拆分成多个细小的服务，部署互相独立、互不影响
- SOA服务化通常组件化模块方式打包在一个War包里，然后统一部署在一个应用服务器中
粒度不同
- 微服务倡导拆得更细，甚至小到不能再进行拆分
- SOA对粒度没有要求，通常粗粒度，强调接口契约的规范化
核心要点和实现原理
- 团队的划分方法是我们首先要考虑的一个核心要素，服务独立UI、后台、DBA、运营和运维人员
- 去中心化治理
- 读者容错模式：尽最大努力获取所需的内容
- 消费者驱动契约模式
- 提供者契约：以提供者为中心，消费者无条件遵守提供者的契约使用服务；
- 消费者契约：基于场景需求发现未明确的提供者契约；
- 消费者驱动契约：向所有当前消费者承诺遵守的约束，一旦确定不再打破。
- 去数据共享模式：交互通过定义良好的接口来实现，不允许使用共享数据来实现
- 服务间交互除了接口契约，还存在数据存储契约
- 上游的数据格式变化时，可能导致下游的处理逻辑出现问题
- 对资源服务的运维难以划清职责和界限
- 跨机房难以服务自治
微服务粒度
拆分到可以让使用方自由编排底层的子服务来获取响应的组合服务即可，同时要考虑团队的建设的数量和分配等
微服务项目层级结构
- 服务导出层
- 服务接口层
- 服务实现层