在服务化的基础上进一步演化出来了微服务架构，微服务是服务化的进一步发展，微服务是去 "ESB" 的更细致的服务化
“微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务和服务之间采用轻量级的通信机制相互沟通（通常是基于HTTP的Restful API).每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构"---- Martin Fowler的博客
当项目进行服务化改造的时候，这个过程并不是一蹴而就，一拍脑袋就成功了。要把项目服务化，需要解决很多的问题，例如：
服务之间怎么调用？订单服务想要调用到商品服务的数据，怎么调用？怎么调用更加的稳定，更加高效？【服务调用技术】
服务之间怎么负载均衡？订单服务要调用商品服务，商品服务可能有很多个，怎么负载均衡【负载均衡技术】
服务怎么被管理？服务怎么定位？有故障了怎么处理？【服务注册与发现技术】
故障怎么监控？微服务系统中业务模块很多，组件也很多，不同组件的指标不同，那么这些组件怎么进行监控【监控技术】
故障怎么定位？微服务架构中，一个用户的请求会涉及到多个内部服务的调用，那么如何定位问题呢？【链路追踪技术】
日志怎么分析处理？业务模块多了，日志也就多了，直接查看日志文件已经变的不显示了，那么如何对日志进行分析查找呢？【日志分析技术】
权限管理？微服务拆分服务之后，会有很多服务对外暴露接口，这些接口如何进行统一的权限处理呢？【网关技术】
服务调用出现问题怎么处理？当一个服务因为各种原因停止响应时，调用方通常会等待一段时间，然后超时或者收到错误返回。如果调用链路比较长，可能会导致请求堆积，整条链路占用大量资源一直在等待下游响应。怎么解决呢？【服务熔断，降级，限流】
基于 Kubernetes + ServiceMesh 的云原生微服务架构
微服务 2.0 更多的注重服务的治理，2.0 阶段，微服务架构引入了 ServiceMesh（服务网格）的概念通过 SideCar(侧边车)的方式实现一些对应用无侵入的管理，
使得服务治理更加通用，借助 Service Mesh 可以更方便的管理服务间调用，更好的做流量控制等
追本溯源，服务网格从无到有可分为三个演化阶段（参见下图）。
第一个阶段，每个服务各显神通，自行处理对外通讯。
第二个阶段，所有服务使用统一的类库进行通讯。
第三个阶段，服务不再关心通讯细节，统统交给边车进程，就像在TCP/IP协议中，应用层只需把要传输的内容告诉TCP层，由TCP层负责将所有内容原封不动的送达目的端，整个过程中应用层并不需要关心实际传输过程中的任何细节。
Kubernetes 让微服务更简单，使用 Kubernetes 就无需关注服务的注册发现了，服务部署自动服务注册发现，无需在应用代码里向服务中心注册，kubernetes 让微服务的缩放更为简单，你也可以配置根据应用的 CPU 等指数来实现应用的动态扩容，压力大的时候自动扩容，增加节点，压力小的时候自动缩放，减少服务节点。