微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多SOLID原则。微服务架构是个很有趣的概念，它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念：把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义：围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
1.2 传统开发模式和微服务的区别传统的web开发方式
通过对比比较容易理解什么是Microservice Architecture。和Microservice相对应的，这种方式一般被称为Monolithic（单体式开发）。所有的功能打包在一个 WAR包里，基本没有外部依赖（除了容器），部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。
优点：
开发简单，集中式管理
基本不会重复开发
功能都在本地，没有分布式的管理和调用消耗
缺点：
效率低：开发都在同一个项目改代码，相互等待，冲突不断
维护难：代码功功能耦合在一起，新人不知道何从下手
不灵活：构建时间长，任何小修改都要重构整个项目，耗时
稳定性差：一个微小的问题，都可能导致整个应用挂掉
扩展性不够：无法满足高并发下的业务需求
常见的系统架构遵循的三个标准和业务驱动力：
提高敏捷性：及时响应业务需求，促进企业发展
提升用户体验：提升用户体验，减少用户流失
降低成本：降低增加产品，客户或业务方案的成本
基于微服务架构的设计
目的：有效的拆分应用，实现敏捷开发和部署
关于微服务的一个形象表达
X轴：运行多个负载均衡器之后的运行实例
Y轴：将应用进一步分解为微服务（分库）
Z轴：大数据量时，将服务分区（分表）
官方定义
一些列的独立的服务共同组成系统
单独部署，跑在自己的进程中
每个服务为独立的业务开发
分布式管理
非常强调隔离性
大概的标准
分布式服务组成的系统
按照业务，而不是技术来划分组织
做有生命的产品而不是项目
强服务个体和弱通信（ Smart endpoints and dumb pipes ）
自动化运维（ DevOps ）
高度容错性
快速演化和迭代
1.4 怎么具体实践微服务客户端如何访问这些服务 - API Gateway
原来的单体开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的 Java进程了。客户端UI如何访问他的？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不符合我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。
所以一般在后台N个服务和UI之间一般会一个代理或者叫 API Gateway，他的作用包括：
提供统一服务入口，让微服务对前台透明
聚合后台的服务，节省流量，提升性能
提供安全，过滤，流控等API管理功能
其实这个API Gateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作 用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过API Gateway也有可能成为单点故障点或者性能的瓶颈。用过Taobao Open Platform（淘宝开放平台）的就能很容易的体会，TAO就是这个API Gateway。
每个服务之间如何通信 - IPC