一、单体架构
1.1、简介
一个归档包包含了应用所有功能的应用程序， 我们通常称之为单体应用。
架构单体应用的架构风格， 我们称之为单体架构， 这是一种比较传统的架构风格。
1.2、单体架构存在的缺点
复杂性逐渐变高、技术债务逐渐上升、部署速度逐渐变慢、阻碍技术创新、无法按需伸缩
1.3、架构的演进
单体架构→SOA→微服务
二、微服务
2.1、Martin Fowler定义
Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
来自：http://www.martinfowler.com/articles/microservices.html
2.2、 微服务具备的特性
1. 每个微服务可独立运行在自己的进程里；
2. 一系列独立运行的微服务共同构建起了整个系统；
3. 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，推荐数据库独立，比如：订单管理、用户管理等；
4. 微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用。
5.服务自动化部署，集中化管理，具有分布式架构，熔断机制等
针对以上，打车架构货站
2.3、微服务优点
易于开发和维护、启动较快、局部修改容易部署、技术栈不受限、按需伸缩、DevOps
2.4、微服务带来的挑战
运维要求较高、分布式的复杂性、接口调整成本高、重复劳动
2.5、微服务设计原则
单一职责原则、服务自治原则、轻量级通信原则、接口明确原则
2.6、微服务开发框架浅谈
Spring Cloud：http://projects.spring.io/spring-cloud
Dubbo：http://dubbo.io
Dropwizard：http://www.dropwizard.io
Consul、etcd &etc.
三、示例
3.1、构建打车软件六边形架构模型
应用的核心是商业逻辑，它由定义服务、域对象和事件各模块来完成。各种适配器围绕核心与外部交互。适配器包括数据库访问组件、生成和 consume 信息的消息组件，以及提供 API 或者 UI 访问支持的 web 模块。
尽管拥有逻辑缜密的模块化设计，整个应用仍然以整体打包和部署，实际格式依赖于应用的语言和框架。譬如，许多 Java 应用被打包为 WAR 文件，部署在 Tomcat 或者 Jetty 这样的应用服务器。有些 Java 应用本身就是包涵 JARs 的软件包。
3.2、可能的系统分解图
一个微服务一般完成某个特定的功能，比如订单管理、客户管理等。每个微服务都是一个微型应用，有着自己六边形架构，包括商业逻辑和各种接口。有的微服务通过暴露 API 被别的微服务或者应用客户端所用；有的微服务则通过网页 UI 实现。在运行时，每个实例通常是一个云虚拟机或者 Docker 容器。
应用的每个功能区都由其自身微服务实施。此外，整个网页应用被拆分为一套简单的网页应用（比如我们的打车软件拆分为乘客应用和司机应用），从而能够轻松地针对特定用户、设备或者用户案例进行单独部署。
每个后端服务包括一个 REST API 和由其它服务提供的服务消耗 API。例如，司机管理服务使用“通知”服务器来告知司机即将的行程。UI 服务唤醒其它服务，从而呈现网页。这些服务也可能用到基于信息的异步通信。内部服务通信会在本系列文章中详述。
有的 REST API 也对司机和乘客的移动应用开放。这些应用并不能直接访问后端服务器，相反，通信由名为 API Gateway 的中间人调解。AIP Gateway 负责负载均衡、缓存、访问控制、API 计费、监控等，通过 NGINX 高效实施。本系列的后续文章将会讲解 API Gateway。
上图是 Scale Cube 的 3D 模型，来自《The Art of Scalability》 一书。微服务架构范式对应 Y 轴，X 轴由负载均衡器后端运行的多个应用副本组成，Z 轴（数据分割）将需求路由到相关服务。
应用通常同时使用这三种不同类型的扩展。Y 轴扩展将应用分解为如图一（https://www.nginx.com/wp-content/uploads/2015/05/Graph-031-e1431992337817.png）所示的微服务。在运行时维度，X 轴扩展在输出和可用性的负载均衡后运行多个实例。部分应用会使用 Z 轴扩展来对服务进行数据分割。下图展示了行程管理服务（Trip Management）是如何使用 Docker 部署到 AWS EC2 上的。
在运行时，行程管理服务包括多个服务实例，每个服务实例都是一个 Docker 容器。为了实现高可用性，这些容器运行在多个云虚拟机上。在应用实例前面是 NGINX 这样的负载均衡，将请求分发给全部实例。负载均衡也可以处理缓存、访问控制、 API 测量和监控等。
微服务架构范式对应用和数据库的关系影响巨大。每个服务都有自身的数据库计划，而不与其它服务共享同一个数据库。一方面，这个方法类似企业级数据模型。同时，它也导致部分数据的重复。然而，要想从微服务中获益，为每个服务提供单个的数据库计划就非常必要，这能保证松散耦合。下面的图表展示了示例应用的数据库架构。
每个服务都有其自己的数据库。此外，单个服务可以使用符合自己需要的特定类型的数据库，即多语言一致性架构。例如，为了发现附近乘客，驾驶员管理服务必须使用高效支持地理位置请求的数据库。
表面上看，微服务架构范式与 SOA 非常类似，这两种架构都包括一套服务。然而，微服务架构范式被看作不包含某些功能的 SOA 。这些功能包括网络服务说明（ WS-* ）和 Enterprise Service Bus (ESB) 的商品化和请求包。基于微服务的应用更青睐 REST 这样简单的、轻量级的协议，而不是 WS-* 。他们也极力避免在微服务中使用 ESBs 及类似功能。微服务架构范式也拒绝 SOA 的其它部分，比如 canonical schema 的概念。
原文地址：http://blog.daocloud.io/microservices-1/
英文地址：https://www.nginx.com/blog/introduction-to-microservices/