微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。（微服务的概念源于2014年3月Martin Fowler Microservices”(http://martinfowler.com/articles/microservices.html)。
类似的定义：微服务采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信，例如 RPC、HTTP 等，服务可独立扩展伸缩，每个服务定义了明确的边界，不同的服务甚至可以采用不同的编程语言来实现，由独立的团队来维护。
二、微服务通用特性
微服务有以下几个特征：1. 通过服务实现组件化；2. 按业务能力来划分服务与组织团队；3. 服务即产品；4. 智能终端与哑管道；5. 去中心统一化；6. 基础设施自动化；7. Design for failure；8. 进化设计。（参考blog.csdn.net/mindfloating/article/details/24583369）
1. 通过服务实现组件化
传统实现组件的方式是通过库（library），传统组件是和应用一起运行在进程中，组件的局部变化意味着整个应用的重新部署。 通过服务来实现组件，意味着将应用拆散为一系列的服务运行在不同的进程中，那么单一服务的局部变化只需重新部署对应的服务进程。 另外将服务作为组件可以更明确的定义出组件的边界，因为服务之间的调用是跨进程的，清晰的边界和职责定义是设计时必须考虑的。
2. 按业务能力来划分服务与组织团队
康威定律（Conway's law）指出：
organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations.
任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。
传统开发方式中，我们将工程师按技能专长分层为前端层、中间层、数据层，前端对应的角色为UI、页面构建师等，中间层对应的角色为服务端业务开发工程师，数据层对应着DBA等角色。 事实上传统应用设计架构的分层结构正反应了不同角色的沟通结构。 而微服务架构的开发模式不同于传统方式，它将应用按业务能力来划分为不同的服务，每个服务都要求在对应业务领域的全栈（从前端到后端）软件实现，从界面到数据存储到外部沟通协作等等。 因此团队的组织是跨功能的，包含实现业务所需的全面的技能。 近年兴起的全栈工程师正是因为架构和开发模式的转变而出现，当然具备全栈的工程师其实很少，但将不同领域的工程师组织为一个全栈的团队就容易的多。
3. 服务即产品
传统的应用开发都是基于项目模式的，开发团队根据一堆功能列表开发出一个软件应用并交付给客户后，该软件应用就进入维护模式，由另一个维护团队负责，开发团队的职责结束。 而微服务架构的倡导者提议避免采用这种项目模式，更倾向于让开发团队负责整个产品的全部生命周期。Amazon 对此提出了一个观点：
You buidl it, you run it.
开发团队对软件在生产环境的运行负全部责任，让服务的开发者与服务的使用者（客户）形成每天的交流反馈，来自直接客户端的反馈有助于开发者提升服务的质量。
4. 智能终端与哑管道
微服务架构抛弃了 ESB 过度复杂的业务规则编排、消息路由等。 服务作为智能终端，所有的业务智能逻辑在服务内部处理，而服务间的通信尽可能的轻量化，不添加任何额外的业务规则。
5. 去中心统一化
传统应用中倾向采用统一的技术平台或产品来解决所有问题。 不是每个问题都是钉子，也不是每个解决方案都是一个锤子。 问题有其具体性，解决方案也应有其针对性。 用最适合的技术方案去解决具体的问题，在大一统的传统应用中其实很难做到，而微服务的架构意味着，你可以针对不同的业务服务特征选择不同的技术平台或产品，有针对性的解决具体的业务问题。
6. 基础设施自动化
单一进程的传统应用被拆分为一系列的多进程服务后，意味着开发、调试、测试、集成、监控和发布的复杂度都会相应增大。 必须要有合适的自动化基础设施来支持微服务架构模式，否则开发、运维成本将大大增加。
7. Design for failure
正因为将服务独立在不同的进程中后，引入了额外的失败因素。 任何时刻对服务的调用都可能因为服务方不可用导致失败，这就要求服务的消费方需要优雅的处理此类错误。 这其实是相对传统应用开发方式的一个缺点，不过随着一些开源服务化框架的出现，对业务开发人员而言适当的屏蔽了类似的错误处理，不过开发人员依然需要知道对服务的调用是完全不同于进程内的方法或函数调用的。
8. 进化设计
一旦采用了微服务架构模式，那么在服务需要变更时我们要特别小心，服务提供者的变更可能引发服务消费者的兼容性破坏，时刻谨记保持服务契约（接口）的兼容性。 对于解耦服务消费方和服务提供方，伯斯塔尔法则（Postel's law）特别适用：
Be conservative in what you send, be liberal in what you accept.
发送时要保守，接收时要开放。
按照伯斯塔尔法则的思想来设计实现服务调用时，发送的数据要更保守，意味着最小化的传送必要的信息，接收时更开放意味着要最大限度的容忍信息的兼容性。 多余的信息不认识可以忽略，而不应该拒绝或抛出错误。
三、微服务设计原则
采用微服务架构面临的第一个问题就是如何将一个单一应用拆分为多个服务。 有一个一般的原则是，单一服务提供的功能是可以独立被替换和升级的。 也就是说如果有 A 和 B 两个功能，如果 A 功能发生变化时同时 B 功能也需要变化，那么 A 和 B 这两个功能应该被划在一个服务中。
四、微服务与SOA区别
参考地址：http://blog.csdn.net/mindfloating/article/details/24583369
https://www.zhihu.com/question/37808426
https://www.ibm.com/developerworks/community/blogs/3302cc3b-074e-44da-90b1-5055f1dc0d9c/entry/%E8%A7%A3%E6%9E%90%E5%BE%AE%E6%9C%8D%E5%8A%A1%E6%9E%B6%E6%9E%84_%E4%B8%80_%E4%BB%80%E4%B9%88%E6%98%AF%E5%BE%AE%E6%9C%8D%E5%8A%A1?lang=es