1. 企业IT建设的三大基础环境
团队协作环境：主要是DevOps领域的范畴，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。
个人基础环境：就是本文介绍的微服务应用平台，他的目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。
IT基础设施：就是我们通常说的各种运行环境支撑如IaaS (VM虚拟化)和CaaS (容器虚拟化)等实现方式。
2. 微服务应用平台总体架构
主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分的。
开发集成：主要是搭建一个微服务平台需要具备的一些工具和仓库
运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微服务运行容器则会运行在这个平台之上。
监控治理：则是致力于在运行时能够对受管的微服务进行统一的监控、配置等能力。
服务网关： 则是负责与前端的WEB应用 移动APP 等渠道集成，对前端请求进行认真鉴权，然后路由转发。
3. 微服务应用平台的运行视图
在运行期，作为一个微服务架构的平台与业务系统，除了业务应用本身外，还需要有接入服务、统一门户、基础服务等平台级服务来保障业务系统的可靠运行。图中的公共服务就是业务处理过程中需要用到的一些可选服务。
4. 微服务平台的设计目标
支撑微服务应用的全生命周期管理，包括从需求、设计、开发、测试、发布（自动打包管理和敏捷可靠发布）和运营（全面监控管理、标准数据采集和运营驱动创新）。
5. 微服务开发：前端、后端和混合
混合项目则是为了兼容传统模式而保留的，为企业应用向微服务架构演进提供过渡方案。
6. 服务契约与API管理
对于前面提到的微服务带来的依赖管理问题，我们可以通过平台提供的API管理能力来解决。服务契约有点类似于web service的wsdl描述，主要描述服务接口的输入输出规格标准和一些服务调用集成相关的规格内容。
7. 服务契约和服务模拟
有了服务契约，我们就可以根据契约自动生成服务的文档和服务模拟测试环境。这样，开发者就可以及时获取依赖服务的变化，调整自己的程序，并且能够方便的进行模拟测试验证。
根据契约生成模拟服务也就是我们常说的服务挡板，这样即使依赖的其他服务还无法提供功能，我们也可以通过挡板来进行联调测试。
8. 服务契约与服务编排
编排能够很大程度上简化分布式服务调用的复杂度，如同步、异步、异步模拟同步、超时重试、事务补偿等，均有服务编排引擎完成。
服务编排的作用和意义很大，可以快速的将已经提供的微服务能力进行组合发布，非常适合业务的快速创新。
但是大家要注意，逻辑流编排的是业务流程，尽量能够简单明了，一眼看上去就明白业务含义。而业务规则推荐采用服务内部进行编码实现。千万不要将我们的 “逻辑流” 图形化服务编排完全取代程序编码，这样就会可能会走入另外一个极端，比如设计出像蜘蛛网一样的逻辑流图，简直就是灾难。
9. 微服务容器
如果没有一个统一的微服务容器，这些能力在每个微服务组件中都需要建设一遍，而且会五花八门，也很难集成到一起。有了统一的微服务运行容器和一些公共的基础服务，前面所提到的微服务架构下部分组件重复建设的问题也迎刃而解。
10. 三方能力集成说明
* API Doc: Swagger UI
* API Mock: Swagger Mock API
* AOP基础框架：Spring Framework
* 微服务容器：Spring Boot
* 服务发布：Spring Web MVC
* 服务注册中心：Spring Cloud - Eureka
* 服务路由：Spring Cloud - Ribbon
* 服务调用：Spring Cloud - Feign
* 服务熔断器：Spring Cloud - Hystrix
* 安全认证：Spring Cloud - Security
* 服务配置中心：Apollo，Spring Cloud - Config
* 服务监控：Spring Boot Admin
11. 服务注册发现路由
以前的单块应用之间互相调用时配置个IP就行了，但在微服务架构下，服务提供者会有很多，手工配置IP地址又变成了一个不可行的事情。那么服务自动注册发现的方案就解决了这个问题。
我们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心，运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡期进行路由用。
12. 统一认证鉴权
安全认证方面，我们基于Spring Security结合Auth2再加上JWT(Json web token)做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。后续在统一认证和权限方面我们产品会陆续推出较完善并且扩展性良好的微服务组件，可以作为微服务平台的公共的认证和鉴权服务。认证鉴权一定是个公共的服务。
13. 日志与流水设计
先来看日志，平台默认回会提供的日志主要有三种，系统日志，引擎日志还有跟踪日志。有了这些日志，在出问题的时候能够帮助我们获取一些关键信息进行问题定位。
系统日志：格式化日志，记录系统边界报文日志，即微服务接入，接出的请求、响应报文明细信息
引擎日志：格式化日志，记录微服务内部的关键模块的处理情况、上下文状态、耗时等信息；逻辑处理、SQL、服务调用
跟踪日志：非格式化日志，用以开发测试期排错，上线后默认记录异常
要想做到出了问题能够追根溯源，流水号的设计也是非常重要的，日志与各种流水号配合，能够让我们快速定位问题发生的具体时间地点以及相关信息，能够快速还原业务交易全链路。
* GlobalId: 全局流水号，需保证全局唯一，用于标识一次完整的端到端交易
* BusinessId：交易流水号，业务域内唯一，用于标识一次接收到的交易请求
* AppUniqueId：业务处理流水号，应用内部唯一，标识微服务内部收到请求后的一次完整的处理过程
* RequestId：请求消息编号，唯一确定一个请求报文
* ResponseId：响应消息编号，唯一确定一个响应报文
* AppId：应用编号，一个微服务应用集群唯一
* ProcessId：进程编号，微服务集群内唯一
14. 集中配置管理
配置文件主要有运行前的静态配置和运行期的动态配置两种。静态配置通常是在编译部署包之前设置好。动态配置则是系统运行过程中需要调整的系统变量或者业务参数。
就是需要运行时需要有个配置中心来统一管理业务系统中的配置信息，这个就需要平台来提供配置中心服务和配置管理门户。
15. 统一管理门户
微服务架构下，一个大的EAR、WAR应用被拆为了多个小的可独立运行的微服务程序，通常这些微服务程序都不再依赖应用服务器，不依赖传统应用服务器的话，应用服务器提供管理控制台也就没得用了，所以微服务的运行时管理需要有统一的管理门户来支撑。我们规划了的统一集中的微服务门户，可以支撑 应用开发、业务处理、应用管理、系统监控等。
16. 分布式事务问题
我们这里说的事务一致性，不是传统说的基于数据库实现的技术事务。微服务之间是独立的、调用协议也是无状态的，因此数据库事务方案在一开始就已经不再我们考虑的范围内。我们要解决的是一定时间后的数据达到最终一致状态，准确的说就是采用传统的业务补偿与冲正方式。
推荐的事务一致性方案有三种：
可靠事件模式：即事件的发送和接收保障高可靠性，来实现事务的一致性。
补偿模式：Confirm Cancel ，如果确认失败，则全部逆序取消。
TCC模式：Try Confirm Cancel ，补偿模式的一种特殊实现 通常转账类交易会采用这种模式。
17. 分布式同步调用问题
如何在不确定的环境中交付确定的服务
这句话可以简单理解为，我所依赖的服务的可靠性是无法保证的情况下，我如何保证自己能够正常的提供服务，不被我依赖的其他服务拖垮?
我们推荐SEDA架构来解决这个问题。
SEDA : staged event-driven architecture本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。
18. 持续集成与持续交付设计
在运维方面，首先我们要解决的就是持续集成和持续交付，而微服务应用平台的职责范围目前规划是只做持续集成，能够方便的用持续集成环境把程序编译成介质包和部署包。
19. 微服务平台与容器云、DevOps的关系
就微服务应用平台本身来说，并不依赖DevOps和容器云，开发好的部署包可以运行在物理机、虚拟机或者是容器中。
然而当微服务应用平台结合了DevOps和容器云之后，我们就会发现，持续集成和交付变成了一个非常简单便捷并且又可靠的过程。
简单几步操作，整套开发、测试、预发或者生产环境就能够搭建完成。整个过程的复杂度都由平台给屏蔽掉了，通过三大基础环境的整合，我们能够使分散的微服务组件更简单方便的进行统一管理和运维交付。