微服务架构是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。它的主要作用是将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。
概念
把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。
定义
围绕业务领域组件来创建应用，这些应用可独立地进行开发、管理和迭代。在分散的组件中使用云架构和平台式部署、管理和服务功能，使产品交付变得更加简单。
本质
用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。
PS： 微服务这个概念是 2012 年出现的，作为加快 Web 和移动应用程序开发进程的一种方法，2014 年开始受到各方的关注，同年为微服务的元年；
传统架构与微服务架构的区别
系统架构需要遵循的三个标准
提高敏捷性：及时响应业务需求，促进企业发展
提升用户体验：提升用户体验，减少用户流失
降低成本：降低增加产品、客户或业务方案的成本
传统的开发模式
先来看看传统的 WEB 开发方式，通过对比比较容易理解什么是 微服务架构。和 微服务 相对应的，这种方式一般被称为 单体式开发（Monolithic）。
既所有的功能打包在一个 WAR 包里，基本没有外部依赖（除了容器），部署在一个 JavaEE 容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI 等所有逻辑。
优点
开发简单，集中式管理
基本不会重复开发
功能都在本地，没有分布式的管理和调用消耗
缺点
效率低：开发都在同一个项目改代码，相互等待，冲突不断
维护难：代码功功能耦合在一起，新人不知道何从下手
不灵活：构建时间长，任何小修改都要重构整个项目，耗时
稳定性差：一个微小的问题，都可能导致整个应用挂掉
扩展性不够：无法满足高并发下的业务需求
微服务架构
目的
有效的拆分应用，实现敏捷开发和部署
开发和交付中的伸缩立方
X轴： 运行多个负载均衡器之后的运行实例
Y轴： 将应用进一步分解为微服务（分库）
Z轴： 大数据量时，将服务分区（分表）
分库：将业务拆分，拆成微服务，把每个服务的表单独放在数据库里。
分表：用long类型的id号，数据插入的时候有尾数，尾部插入1234567890任意数字对应其对应的表
微服务的特征
官方的定义
一系列的独立的服务共同组成系统
单独部署，跑在自己的进程中
每个服务为独立的业务开发
分布式管理
非常强调隔离性
大概的标准
分布式服务组成的系统
按照业务，而不是技术来划分组织
做有生命的产品而不是项目
强服务个体和弱通信（ Smart endpoints and dumb pipes ）
自动化运维（ DevOps ）
高度容错性
快速演化和迭代
SOA 架构与微服务架构的区别
soa面向服务架构
注重重用，微服务注重重写
SOA 的主要目的是为了企业各个系统更加容易地融合在一起。
微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。我们向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始。
把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后 单独布署。它通常不依赖其他服务。微服务中常用的 API Gateway 的模式主要目的也不是重用代码。
而是减少客户端和服务间的往来。API gateway 模式不等同与 Facade 模式，我们可以使用如 Future 之类的调用，甚至返回不完整数据。
注重水平服务，微服务注重垂直服务
SOA 设计喜欢给服务分层(如 Service Layers 模式)。我们常常见到一个 Entity 服务层的设计，美其名曰 Data Access Layer。这种设计要求所有的服务都通过这个 Entity 服务层。来获取数据。这种设计非常不灵活，比如每次数据层的改动都可能影响到所有业务层的服务。而每个微服务通常有它自己独立的 Data Store。我们在拆分数据库时可以适当的做些去范式化，让它不需要依赖其他服务的数据。
微服务通常是直接面对用户的，每个微服务通常直接为用户提供某个功能。类似的功能可能针对手机有一个服务，针对机顶盒是另外一个服务。在 SOA 设计模式中这种情况通常会用到 Multi-ChannelEndpoint 的模式返回一个大而全的结果兼顾到所有的客户端的需求
注重自上而下，微服务注重自下而上
SOA 架构在设计开始时会先定义好服务合同。它喜欢集中管理所有的服务，包括集中管理业务逻辑，数据，流程，Schema 等。它使用 Enterprise Inventory 和 Service Composition 等方法来集中管理服务。SOA 架构通常会预先把每个模块服务接口都定义好。模块系统间的通讯必须遵守这些接口，各服务是针对他们的调用者。
SOA 架构适用于 TO GAF 之类的架构方法论。
微服务则敏捷得多。只要用户用得到，就先把这个服务挖出来。然后针对性的，快速确认业务需求，快速开发迭代
总结
微服务与 SOA 有很多相同之处。两者都属于典型的、包含松耦合分布式组件的系统结构。在围绕着服务的概念创建架构这一方面，微服务提供了一种更清晰、定义更良好的方式。微服务的原则与敏捷软件开发思想是高度一致的，而它与 SOA 原则的演化的目标也是相同的，则减少传统的企业服务总线开发的高复杂性。两者之间最关键的区别在于，微服务专注于以自治的方式产生价值。但是两种架构背后的意图是不同的：SOA 尝试将应用集成，一般采用中央管理模式来确保各应用能够交互运作。微服务尝试部署新功能，快速有效地扩展开发团队。它着重于分散管理、代码再利用与自动化执行。
微服务并不是一种新思想的方法。它更像是一种思想的精炼，一种 SOA 的精细化演进，并且更好地利用了先进的技术以解决问题，例如容器与自动化等。所以对于我们去选择服务技术框架时，并不是非黑即白，而是针对 SOA、MSA 两种架构设计同时要考虑到兼容性，对于现有平台情况架构设计，退则守 SOA，进则攻 MSA，阶段性选择适合的。
