架构演进
传统应用：
- 服务内部用户为主
- 需求明确
- 功能全
- 覆盖广、大集成、中央控制、稳定发展
- 难以快速变化
新兴互联网应用：
- 服务外部客户和合作伙伴
- 需求变动快
- 功能简单、独立和分散
- 一切从0开始
- 规模变化大，大范围尝试
设计原则
- AKF 扩展拆分
- 前后端分离
- 无状态服务
- Rest 通信风格
AKF 扩展拆分
- X轴：水平复制，服务可以部署多个实例，做均衡负载的模式
- Z轴：基于类似的数据分区
- Y轴：基于不同的业务拆分
服务拆分：
- 按照不同的服务功能进行拆分
拆分要点：
- 低耦合、高内聚：一个服务完成一个独立功能
- 按照团队结构，快速迭代
前后端分离(直接采用物理分离的方式部署)
- 前后端技术分离，可以由各自的专家对各自的领域进行优化，前段的用户体验优化效果更好
- 分离模式下，前后端交互界面更加清晰，剩下了接口和模型，后端的接口简单明了，更容易维护
- 前端多渠道集成场景更容易实现，采用统一的数据和模型，可以支撑前端的web UI和移动App等访问
无状态服务
-
状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态，进而依赖这个状态数据的服务被称为有状态服务，反之称为无状态服务
-
无状态服务原则：不是说微服务架构中不允许存在状态，表达的是把有状态的业务服务改变成无状态的计算类服务
-
场景说明：以前建立的本地内存数据缓存、session缓存，到现在微服务架构中应该将这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。
Rest 通信风格
- 无状态协议Http
- JSON报文序列化
- 语言无关
微服务架构带来的问题
- 依赖服务接口变更（服务接口如何管理、接口变更跟踪难、依赖服务调试麻烦）
- 不分模块重复构建（安全认证、配置日志）
- 分布式带来的问题（分布式事务问题、依赖服务不稳定、需要引入异步模式）
- 运维复杂度陡增（部署物数量增加、监控进程增加、故障定位难、问题追溯难）
企业IT建设的三大基础环境
- 团队协作环境
- 个人基础环境
- IT基础设施
- 团队协作环境：DevOps领域，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布
- 个人基础环境：支撑微服务应用的设计开发测试、运行期的业务数据处理和应用的管理监控
- IT基础设施：IaaS(VM 虚拟化)、CaaS（容器虚拟化）
微服务应用平台总体架构
微服务应用平台的总体架构，主要从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度划分：
- 开发集成：搭建一个微服务平台需要具备的一些工具和仓库
- 运行时：要有微服务平台来提供一些基础能力和分布式支撑能力，我们的微服务运行容器则会运行在这个平台之上
- 监控治理：在运行时能够对受管的微服务进行统一的监控、配置等能力
- 服务网关：负责与前端的Web应用、移动App等渠道集成，对前端请求进行认证鉴权、路由转发
微服务应用平台运行时视图
微服务平台的设计目标
微服务平台的主要目标主要就是要支撑微服务应用的全生命周期管理，从需求到设计开发测试，运行期的业务数据处理和应用的管理监控等，后续将从应用生命周期的几个重要阶段切入，结合前面提到的设计原则和问题，介绍平台提供的能力支撑情况
微服务容器
我们要做微服务架构的应用，可靠高效的微服务应用，实际上我们需要做的事情还是非常多的。如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。
统一认证鉴权
基于 Spring Security 结合 Auth2 再加上 JWT（Json web token）做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通
日志和流水设计
集中配置管理
-
是配置与介质分离，这个就需要通过制定规范的方式来控制。千万别把配置放在 Jar 包里；
-
是配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架；
-
就是需要运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。
统一管理门户
微服务架构下，一个大的 EAR、WAR 应用被拆为了多个小的可独立运行的微服务程序，通常这些微服务程序都不再依赖应用服务器，不依赖传统应用服务器的话，应用服务器提供管理控制台也就没得用了，所以微服务的运行时管理需要有统一的管理门户来支撑。我们规划了的统一集中的微服务门户，可以支撑 应用开发、业务处理、应用管理、系统监控等
分布式事务问题
我们要解决的是一定时间后的数据达到最终一致状态，准确的说就是采用传统的业务补偿与冲正方式
- 可靠事件模式：即事件的发送和接收保障高可靠性，来实现事务的一致性
- 补偿模式：Confirm Cancel ，如果确认失败，则全部逆序取消
- CC 模式：Try Confirm Cancel ，补偿模式的一种特殊实现 通常转账类交易会采用这种模式
