服务架构是对 Moli
1. 将业务拆分为一个个独立的服务。
2. 服务间通过 REST API 来将服务暴露出去，同时从 消耗服务API 来获取其他模块的服务。
由 《The Art of Scalability》 中的 Scale Cube 3D 模型来展示：
1. 微服务架构范式对应 Y 轴。
2. X轴由负载均衡器后端运行的多个应用副本组成。
3. Z轴（数据分割）将需求路由到相关服务
应用通常使用这三种不同类型的扩展：
Y 轴扩展将应用分解为 下图 所示的微服务：
运行时，行程管理服务包括多个服务实例，每个服务实例都是一个 Docker 容器。
为了实现高可用性，这些容器运行在多个云虚拟机上。
在应用实例前面是 NGINX 这样的负载均衡，将请求分发给全部实例。
负载均衡也可以处理缓存、访问控制、API 测量和监控等。
微服务架构范式对应用和数据库的关系影响巨大。
每个服务都有自身的数据库计划，而不与其他服务共享同一个数据库。
一方面，类似企业级数据模型。
同时，也导致部分数据的重复。
为每个服务提供单个的数据库计划非常必要。保证松散耦合。
每个服务都有其自己的数据库。
此外，单个服务可以使用符合自己需要的特定类型的数据库，即多语言一致性架构。
例如，驾驶管理服务必须使用高效支持地理位置请求的数据库。
微服务架构的好处：
1. 通过分解巨大单体应用为多个服务方法解决了复杂性问题。在功能性不变的情况下，应用被分解为多个
可管理的分支或服务。每个服务都有一个用 RPC -- 或消息驱动 API 定义清楚的边界。
单个服务很容易开发、理解和维护。
2. 微服务架构使得每个服务都可以有专门开发团队来开发。开发团队自由选择开发技术，提供 API 服务。
这种自由意味着开发者不需要被迫使用某项目开始时采用的过时技术，可以选择现在的技术。甚至于，因为服务都是相对简单，即使用现在技术重写以前代码也不是很困难的事情。
3. 微服务架构模式使得每个微服务器独立部署，不需要协调其他服务部署。可加快部署速度，
是的 持续化部署成为可能。
4. 微服务架构模式使得每个服务独立扩展。
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
微服务架构的不足
1. "there are no silver bullets" “微服务”强调了服务大小。
微服务的目的是有效的拆分应用，实现敏捷开发和部署。
2. 微服务应用是分布式系统，固有的复杂性，需要在 RPC 或者 消息传递之间选择并完成进程间通讯机制。
但是，开发者必须写代码来处理消息传递中速度过慢或者不可能等局部失效问题。
但不是什么难事，相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术更复杂一些。
3. 一个关于微服务的挑战来自于分区的数据库架构。同时更新多个业务主体的事务很普遍。
这种事务对于单体式应用来说很容易，因为只有一个数据库。
在微服务架构应用中，需要更新不同服务所使用的不同的数据库。
不仅仅是 CAP 理论，当前高扩展的 NoSql 数据库和消息传递中间件并不支持这一需求。需要一个最终一致性的方法。
4. 测试基于微服务架构的应用也很复杂。
微服务架构模式应用的改变会波及多个服务。幸运的是，许多改变一般只影响一个服务。
部署一个微服务应用也很复杂，一个单体应用需要在复杂均衡器后面部署给自的服务器就好了。
每个应用实例需要配置诸如数据库和消息中间件等基础服务。
相比之下，一个微服务应用一般由大批服务构成。每个应用实例是需要配置诸如数据库和消息中间件等基础服务。
很多的服务实例，就形成大量需要配置、部署、扩展和监控的部分。
除此之外，需要完成一个服务发现机制，以用来发现与它通讯服务的地址（包括服务器地址和端口）
以用来发现与它通讯服务的地址（包括服务器地址和端口）。
成功部署一个微服务应用需要开发者有足够的控制部署方法，并高度自动化。
自动化的方法之一是使用 譬如 Cloud Foundry 这样的 PaaS 服务。让开发者轻松部署和管理微服务。，让他们
无需为获取并配置 IT 资源。配置 PaaS 的系统和网络专家可以采用最佳实践和策略来简化这些问题。
另一个自动部署微服务应用的方法是开发自己的基础 PaaS 系统。
通常的起步方式是 Mesos 或 Kubernetes 这样的集群管理方案，配合 Docker 使用。
作为一种基于软件的应用交付方法， NGINX 能够方便地在微服务层面提供
1. 缓冲
2. 权限控制
3. API统计
4. 监控
-----------备注------------- （感谢技术分享）
[ Chris Richardson 微服务系列]
1 -- Ngnix 官方博客 微服务系列文章
2 -- 网页： blog.daocloud.io/microservices-1/