什么是微服务?
微服务是一些协同工作的小而自治的服务。
一个微服务就是一个独立的实体，它可以独立地部署在PAAS上，尽量避免把多个服务部署到同一天机器上。服务之间均通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。服务会暴露API，然后服务之间通过这些API进行通信。
技术异构性：在一个由多个服务互相协作的系统中，可以在不同的服务中使用最适合该服务的技术。
高内聚：把因相同原因而变化的东西聚合在一起，把因不同原因而变化的东西分离开来
松耦合：能独立修改部署单个服务而不需要修改系统的其他部分，一个松耦合的服务应该尽可能少地知道与之协作的那些服务的信息，应该限制两个服务之间不同调用形式的数量，因此过度的同学可能会导致紧耦合。
限界上下文：组织内高内聚和低耦合的边界。
SOA（Service-Oriented Architecture）是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列的功能。一个服务通常以独立的形式存在于操作系统进程中。
理想的微服务集成技术能带来什么
² 避免破坏性修改
² 保证API的技术无关性
² 使服务易于消费者使用
² 隐藏内部实现细节
微服务之间如何协作
使用同步通信，发起一个远程服务调用后，调用方会阻塞自己并等待整个操作的完成。一般使用请求响应协作方式，客户端发起一个请求，然后等待响应
使用异步通信，调用方不需要等待操作完成就可以返回，甚至可能不需要关心这个操作完成与否。处理异步通信的技术较复杂，需要低延迟时使用。一般使用基于事件的协作方式，客户端发布一个事件，然后期待其他协作者接受的该消息，并且知道该怎么做。也就是说业务逻辑并非集中存在于某个核心大脑，而是平均分布在不同的协作者中。
监控实施建议
对每个服务而言：
² 最低限度要跟踪请求响应时间，做好之后，可以开始跟踪错误率及应用程序级的指标
² 最低限度要跟踪所以下游服务的健康状态，包括下游调用的响应时间，最好能够跟踪错误率。一些像Hystrix（一个基于JVM的断路器，附带强大的监控）这样的库，可以在这方面提供帮助
² 标准化如何收集指标以及存储指标
² 如果可能的话，以标准的格式将日志记录到一个标准的位置，如果每个服务各自使用不同的方式，聚合会非常痛苦
² 监控底层操作系统，这样你就可以跟踪流氓进程和进行容量规划
对系统而言：
² 聚合CPU之类的主机层级的指标及应用程序级指标
² 确保你你选用的指标存储工具可以在系统和服务级别做聚合，同时也允许你查看单台主机的情况。
² 确保指标存储工具允许你维护数据足够长的时间，以了解你的系统的趋势
² 使用单个可查询工具来对日志进行聚合和存储
² 强烈考虑标准化关联标识的使用
² 了解什么样的情况需要行动，并根据这些信息构造相应的警报和仪表盘
² 调查对各种指标聚合方式做统一化的可能性，像Suro或Riemann这样的工具可能会对你有用
康威定律
任何组织在设计一套系统系统时，所交付的设计方案在结构上都与该组织的沟通结构保持一致
断路器
使用断路器时，当对下游资源的请求发生一定数量的失败后，断路器会打开，接下来，所有的请求在断路器打开的状态下，会快速地失败，一段时间后，客户端发送一些请求查看下游服务是否已经恢复，如果它得到了正常的响应，将重置断路器。
幂等
对幂等操作来说，其多次执行所产生的影响均与一次执行的影响相同。如果操作是幂等的，我们可以对其重复多次调用，而不必担心会有不利影响。当我们不确定操作是否被执行，想要重新处理消息，从而从错误中恢复时，幂等会非常有用。
垂直扩展
一个有着更快的CPU和更好的I/O的机器，通常可以改善延迟和吞吐量，允许你在更短的时间内处理更多的工作。这种形式的扩展通常被称为垂直扩展，代价昂贵。并且这种扩展无法改善服务器的弹性。
CAP定理
在分布式系统中有三方面需要彼此权衡：一致性（consistency，当访问多个节点时能得到同样的值）、可用性（available，每个请求都能获得响应）、分区容忍性（partition tolerance，集群中的某些节点在无法联系后，集群整体整体还能继续进行服务的能力），CAP定理认为最多只能保证三个中的两个。
在很多情况下，AP系统都是最终正确的选择。CP系统的构建比较复杂，而本身无法解决我们面临的所有问题。
微服务原则
