一、什么是cloud native
Cloud Native （国内译为“云原生”），最早是 Matt Stine 提出的一个概念。与微服务一样，Cloud Native 并不是一种具体的技术，而是一类思想的集合，包括DevOps、持续交付（Continuous Delivery）、微服务（MicroServices）、敏捷基础设施（Agile Infrastructure）、康威定律（Conways Law）等，以及根据商业能力对公司进行重组。Cloud Native 既包含技术（微服务，敏捷基础设施），也包含管理（DevOps，持续交付，康威定律，重组等）。所以，Cloud Native 也可以说是一系列Cloud技术、企业管理方法的集合。
Cloud Native 具备有以下特性：
以云为基础架构
云服务
无服务
可扩展
高可用
敏捷
云优先
等等
二、微服务
微服务虽然带来了架构上的优势，但同时也引入了复杂性。我们不得使用一些组件，来解决技术复杂性提高之后带来的问题：
服务注册中心：一个服务可以有多个实例，那么我们在向一个服务发出请求的时候，怎么知道这个服务有哪些实例呢？为了减少手工维护的麻烦，我们需要服务注册中心。每个服务实例在启动时，向注册中心注册自己的IP地址等信息。这样，服务在调用别的服务的接口时，就可以通过注册中心，查询到其他服务的实例，向实例发起请求。沃尔兹总店就是起到注册中心的作用。
负载均衡：由于一个服务可以有多个实例，所以不管是来自外部客户端的请求，还是微服务系统内部服务之间发起的请求，都需要引入负载均衡的机制，来发挥多实例集群的作用。有的书也称这两种负载均衡为服务器端负载均衡和客户端负载均衡，各自具有代表性意义的实现分别是Nginx和Ribbon。
API Gateway：一个外部请求过来之后，我们需要知道这个请求是发给哪个服务的，也就是我们需要一个请求路由的功能，比如/cm/*的请求，要发给客户管理服务，/om/*的请求，要发给订单管理服务。另外，不是所有请求都可以被我们系统处理的，我们需要判断这个请求是否携带一些必要的鉴权信息，并对其进行鉴权，也就是请求过滤的功能。而API Gateway，就是起到了这两个功能，它就像整个微服务系统的门面，所有请求，都要先经过它的处理，才会转发到对应的服务。
微服务系统的衍生组件还有很多，比如对各个服务进行的配置管理的分布式配置中心、各个服务之间进行消息通讯的消息总线和消息驱动机制（上图中的Message Queue）等。