1. 服务的单一职责原则（SOLID设计原则）
一个单元、类、方法，甚至是一个服务，应当只有一件事要做。多个模块共享职责或者单个模块涉及多种职责是不推荐的。
2. 自包含原则
微服务是自托管、独立部署、自治的服务。绑定了所有的依赖：包依赖、运行环境、容器等等。
传统的应用我们打包成war或者ear包，部署到JavaEE服务器上，而微服务打包成jar，包含所有的依赖，独立运行为一个java进程。
1. 服务是一等公民
所有的服务均采用暴露为API节点的方式展现，内部具体的逻辑、实现方式对外都是抽象隔离的。
2. 服务的交互
最为广泛接受的通信方式是JSON+REST。
3. 松耦合
服务之间往往是通过输入输出事件来进行通信的，如消息、HTTP、REST。
4. 服务抽象
不仅仅是对具体实现的抽象，而且包括对外的抽象隔离。
5. 服务复用
适合多场景下各种模式下的服务消费。
6. 无状态
本身不维护状态，如有需要，则会在数据库中或内存中维护。
7. 服务是可发现的
服务会将自己的存在广播出去，以便于被发现。当服务挂掉，则会在微服务体系中清除。
8. 服务间的互操作性
通常采用消息或者Http请求方式进行互操作，如REST/JSON、Protocol Buffer等
9. 可组合型
多个服务编排起来共同提供服务。
从web服务器的选择到托管容器的选择，微服务的托管是轻量级、便携式、容器化的。
可以使用相同语言的不同的版本，也可以是不同的语言来实现不同的服务，服务之间是不会产生影响的。
服务从开发到构建、测试、部署、扩展等等，都是自治的。
开发阶段：采用版本控制（Git）、持续集成（Jenkins）等实现自治
测试阶段：采用Selenium等工具实现自测。
基础设施：采用容器（Docker）集成实现自治。
发布阶段：采用Chef或Puppet发布。
配制信息管理：Ansible可以用于管理配置。
自动部署：Spring Cloud、Kubernetes、Mesos、Marathon均可用于部署。
DevOps、统一日志管理、服务注册、API网关、广泛的监控、服务路由、流程控制机制
分布式数据及逻辑，去中心化的管理。
每个微服务有自己的数据和逻辑：
SOA在处理情景：
将Shopping Logic的实现逻辑在ESB中全部实现，借助于Customer、Product、Order服务的帮助。
在微服务中，Shopping Logic视为相同地位的服务，服务之间同等调用。
SOA的服务注册采用的是静态注册方式，而微服务采用的是动态注册。
通过不断解决当前系统的问题，不断健壮当前的代码。
Fail Fast原则保证了如果当前服务出现了差错，下游服务不会产生额外的压力，他的原则不是去避免错误，而是关注如何在出现错误时尽快恢复。
自愈就是吸取错误的教训，尽快从错误中学会避免错误的方法。
