每个微服务都是一个系统，如果自己来实现，其过程和做业务系统类似，都需要经过需求分析、架构设计、开发、测试、部署上线等步骤。微服务将原本大一统的系统拆分为多个独立运行的微服务，微服务之间的接口数量大大增加，并且微服务提倡快速交付，版本周期短，版本更新频繁。但是微服务需要部署的节点增加了几倍或者十几倍，部署的频率也会大幅提升，综合比较的话，微服务部署的次数时传统服务的的几十倍。这么大的工作量，如果每次都靠人工去处理，则需要投入非常大的人力，也容器出错，造成效率低下，达不到快速交付的目的，因此必须通过这些基础设施平台来完成自动化交付工作。
1. CI/CD流水线
业务应用被分解成微服务后，需要部署运行的系统个数将成倍增加，依靠传统人工方式部署工作量巨大且容易出错。另外，微服务还具有体量小、更新快的特点。由此可见，微服务架构虽然给企业开发者们带来了诸多优势，但同时也让构建、部署和维护这些分布式的微服务系统带来不少难题。面向应用虚拟化运行环境的PaaS平台为微服务提供了理想的载体，容器作为一种轻量级的进程和资源隔离机制，是满足微服务各种需求的最佳手段。利用容器化技术简化微服务创建、集成、部署、运维的整个流程，推动微服务在云端的大规模实践。
部署微服务和它们依赖交互的组件，相比传统单体应用来说，是一个比较复杂的过程。由此可见，实施一个完整的构建自动化流水线是非常重要的。我们采用这种持续交付的方法可以获取很多便利和好处，比如：
（1）有能力在任何时候发布软件
（2）任何完成的构建都可以成为一个发布版本
（3）构建一次，按需部署
2. 镜像管理
作为代码的一部分，由开发人员来负责创建和维护Dockfile。
一个服务对应一个代码仓库，一个代码仓库对应一个镜像仓库。
（1） cmdbservice： CMDB镜像库
（2） bpmservice ：流程中心镜像库
（3）toolsservice ：场景工具中心镜像库
（4）dashboardservice：展现中心镜像库
3. 灰度发布
为了避免在业务服务的过程中进行停系统更新，使对外服务的系统实行灰度发布，能做到7*24小时不中断，无缝升级。全面提升用户使用感知。并且通过灰度发布，可以尝试新的功能点，并且及时获取用户使用的反馈信息。通过PaaS云平台的灰度发布，可以快速迭代开发，快速更替版本。如果一个服务由多个相同的容器运行，灰度发布则先对其中的部分容器先进行升级，可混合让老版本和新版本的容器同时提供服务。如发现新服务没有什么问题，则可以把所有剩下的微服务再全部进行升级。
基于Kubernetes的灰度升级（又称灰度发布、灰度更新）是指在黑与白之间，能够平滑过渡的一种发布方式。ABtest就是一种灰度发布方式，让一部用户继续用A，一部分用户开始用B，如果用户对B没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定，在初始灰度的时候就可以发现、调整问题，以保证其影响度。
4. 业务逻辑实现规范
分中心业务微服务应该是一个或者多个Spring Boot (/Spring Cloud)应用组成，可能实现的技术组件、接口和通用功能特性如下图：
整体组件依赖关系示意图：
（1）resource service (业务微服务应用)
微服务之间的访问机制，和API调用方式
（2）管理接口
通过Rest API来提供服务。
（3）可插拔的序列化
开发时根据需要，从maven导入需要的spring cloud组件来完成相应的服务功能，如配置中心，应用网关和服务注册与发现等。
（4）健康检查
为了实现对Spring Boot Web服务应用的健康检查，我们可以引入Spring Boot Actuator特性。
Actuator使Spring Boot应用程序的具备生产级功能而无需开发人员做实际实现工作。
它们主要用于暴露有关正在运行的应用程序的不同类型的信息 - 健康，指标，信息，转储，环境等。
要开始在Spring Boot中使用现有的Actuator，我们只需要将spring-boot-actuator依赖关系添加到pom：
org.springframework.boot
spring-boot-starter-actuator
1.4.2.RELEASE
端点允许您监视应用程序，在某些情况下也可以与其进行交互。该依赖带有许多内置端点，并且像Spring中的其它功能一样，您也可以自己定制。
这里有一些最常见的端点Boot提供开箱即用：
/ health - 显示应用程序运行状况信息
/ info -显示任意应用程序信息
/ metrics -显示当前应用程序的“度量”信息
/ trace -显示跟踪信息（默认为最后几个HTTP请求）
（5）服务注册与发现以及负载均衡
各个分中心微服务启用服务发现客户端(Eureka Client)，指定服务发现服务器，然后实现服务自注册功能。
Ribbon是一个客户端负载平衡器，可以很好地控制HTTP和TCP客户端的行为。与传统的负载平衡器相比，每次线上调用都不需要额外的跳转 - 可以直接与所需的服务联系。
开箱即用，它原生地集成了Spring Cloud和服务发现。Eureka客户端提供可用服务器的动态列表，因此Robbin可以在它们之间进行平衡。
Feign是一个声明性的Http客户端，与Ribbon和Hystrix无缝集成。实际上，通过一个spring-cloud-starter-feign依赖和@EnableFeignClients注释，您可以使用一整套负载平衡器，断路器和Http客户端，具有明智的即将推出的默认配置。
（6） 限流和容错
限流：
上层框架实现
容错 - Hystrix：
Hystrix是断路器模式的实现，它可以通过网络访问依赖关系来控制延迟和故障。主要思想是在具有大量微服务器的分布式环境中停止级联故障。这有助于快速失败并尽快恢复 - 自我修复的容错系统的重要方面。
除了断路器控制，使用Hystrix，您可以添加一个备用方法，在主命令失败的情况下，将调用该方法来获取默认值。
此外，Hystrix生成每个命令的执行结果和延迟的指标，我们可以用它来监视系统行为。
（7）过滤器插件
过滤器插件负责对请求的处理过程进行干预，是实现请求校验、服务聚合等功能的基础。
（8）REST/RPC接口
各个分中心微服务通过API Gateway对外提供访问API。
（9）安全访问控制
各个分中心的微服务需要有安全访问控制。
（10）日志
集中式日志记录在试图识别分布式环境中的问题时非常有用。 Elasticsearch，Logstash和Kibana技术栈可让您轻松搜索和分析您的日志，利用率和网络活动数据。
（11）度量与跟踪
跟踪可以结合日志和审计功能来实现。
（12）配置
可以通过配置服务进行统一配置和管理。将分中心的配置数据存放到配置服务器侧。
详见1.1.2 Config server, 集中配置数据管理
（13）文档自动生成
在微服务中通过引入swagger核心基础组件，使用swagger的注解在微服务的接口和使用的模型上添加API规范说明。
（14）统一错误处理
微服务通过跟踪异常信息的抛出，找到对应的源码，自定义一些处理逻辑来符合业务的需求。