1.1 什么是微服务
微服务就是一些协同工作的小而自治的服务。
1.1.1 专注于做好一件事
随着新功能的增加，代码库会越变越大。时间久了代码库会非常庞大，以至于想要知道该在什么地方做修改都很困难。在一个单块系统内，通常会创建一些抽象层或者模块来保证代码的内聚性，从而避免上述问题。内聚性是将相关代码放在一起，在考虑使用微服务的时候，内聚性这一概念很重要。
微服务将这一理念应用在独立的服务上。根据业务的边界来确定服务的边界，这样久很容易确定某个功能代码应该放在哪里。而且由于该服务专注于某个边界之内，因此可以很好地避免由于代码库过大衍生出的很多相关问题。
1.1.2 自治性
一个微服务就是一个独立的实体。它可以独立地部署在服务器上。尽量避免把多个服务部署到同一台机器上，尽管这种隔离性会引发一些代价，但它能够大大简化分布式系统的构建。
服务之间通过网络调用进行通信，从而加强了服务之间的隔离性，避免紧耦合。
对于一个服务来说，我们需要考虑的是什么应该暴露，什么应该隐藏。如果暴露得过多，那么服务消费方会与该服务的内部实现产生耦合。服务会暴露出API，然后服务直接通过这些API进行通信。API的实现技术应该避免与消费方耦合。
1.2 主要好处
1.2.1 技术异构性
1.2.2 弹性
1.2.3 扩展
1.2.4 简化部署
1.2.5 与组织结构相匹配
1.2.6 可组合性
1.2.7 对可替代性的优化
松耦合
如果做到了服务之间的松耦合，那么修改一个服务久不需要修改另一个服务。使用微服务最重要的一点是，能够独立修改及部署单个服务而不需要修改系统其他部分。
高内聚
把相关行为聚集在一起，把不相关的行为放在别处。如果你需要改变某个行为的话，最好能够在一个地方进行修改，然后就可以尽快地发布。如果需要在很多不同的地方做这些修改，那么可能就需要同时发布多个微服务才能交付这个功能。在多个不同的地方进行修改会很慢，同时部署多个服务风险也很高。
限界上下文
一个由显示边界限定的特定职责。
当你在思考组织内限界上下文时，不应该从共享数据角度来考虑，而应该从这些上下文能够提供的功能来考虑。
监控
将系统拆分成更小的、细粒度的微服务会带来很多好处。然而它也增加了生产系统的监控复杂性。
监控小的服务，然后聚合起来看整体。
多个服务，多个服务器
你如何在多个主机上的、成千上万行的日志中定位错误的原因？如何确定一个服务器异常，还是一个系统性的问题？如何在多个主机间跟踪一个错误的调用链，找出引起这个错误的原因？
答案是，从日志到应用指标，集中收集和聚合尽可能多的数据到我们的手上。