微服务简介(MicroServices)
微服务是一种架构风格，一个或多个小的微服务组成一个复杂、庞大的软件应用。每个微服务集中在完成一个较小业务能力的任务。这些微服务可以用任意语言开发。
Martin Fowler’s 定义的微服务，微服务用于组成复杂的应用，微服务够小，独立、进程可替代、微服务之间使用轻量级的API， 并且微服务不依赖统一的开发语言
更多信息参考：Martin Fowler的论文“Microservices: A new architectural term”, http://martinfowler.com/articles/microservices.html
微服务多小才算小
微服务大小不是由代码行数决定的，微服务足够小，聚焦在特定目的。微服务应用做一件事情，并且做好这件事情。
独立和自治（independence and autonomy）
为了确保每个服务在创建、维护时保持敏捷性，每个服务应该独立和自治。每个服务能够在任何时间启动、停止、替换，不会紧密与其他服务绑定。微服务其他要素遵循这一点。
微服务架构风格应该扮演一个包装来守护应用的具体实现细节。这种配置允许服务的实现，以后可被修订并且提升（甚至重写）。特别是数据源必须是服务私有的。
弹性和容错（resilience and fault tolerance）
服务需要具有弹性的能力，也就是说在动态的云环境中，服务需要预测和平缓地响应异常，即当服务接收到错误的数据时，不会影响到后台服务（Backing Service），或者处理分布式系统中并发更新的冲突。
独立演进但是相互之间存在依赖关系的服务，鲁棒性原则提供最佳指导：“对接收的可以进行自由操作，对于发出的需要谨慎处理”。 假设API会逐渐演进，对于无法理解的数据能够容错，引用RFC：
简单举例，一个协议包含多个枚举值，这些枚举类一定是不完整的。因此，如果协议定义了4个可能的错误码，当服务接收到第5个错误码时，服务不会宕机。无法识别的编码可能会记录到日志中，但是不会引起错误。
微服务必须避免错误在系统之间进行层级传递。需要设计某种策略处理API的变更引起的变化。分离模式，例如熔断和隔板。
自动化的环境（automated environment）
云环境中的微服务架构，创建一个不规则延伸的独立迁移个体。服务之间的交互关系错综复杂。一个高度自动化的应用对于微服务来说至关重要。
微服务通常需要设计一种策略来进行代码构建和部署，例如持续集成和持续部署。
自动化监控和告警也很重要，虽然独立的服务应该尽可能少的考虑如何管理自己的日志数据，但是他们应该确保合适的日志数据和指标数据能促进自动化的问题检测和告警。
微服务和团队结构
微服务架构和团队组织之间的关系具有一定哲理性。微服务的结构要与人员组织结构一致。根据康威定律（Conway’s law），任何组织所设计的系统，将不可避免的与组织结构一致。