什么是微服务
SOA设计模式：面向服务的架构，需要解决的问题是通信协议如何选择、第三方中间件如何选择、服务粒度如何确定鞥
主要为微服务做定义，以及说明有什么优点与缺点，微服务架构应该是什么样的
微服务就是一些协同工作的小而自治的服务
单一职责原则: 把因相同原因而变化的东西聚合在一起，而把因不同原因而变化的东西分离开来
微服务将这一原则应用在独立的服务中，根据业务的边界来确定服务的边界
仅暴露外部需要的API，避免与消费方耦合
- 弹性: 舱壁，需要做到修改一个服务并对其进行部署，而不影响其他任何服务
- 技术异构性: 使用最合适的技术做相应的服务
- 扩展: 细粒度的优势使得能够做到按需扩展需要的服务，以及简化部署，能够快速回滚
- 与组织结构相匹配，各司其职
- 可组合性: 易于重用已有的服务
- 对可替代性的优化: 轻易的重写已有的服务或者进行删除
这章最后提醒了，微服务并不是一个通用的法则，要得到这些好处，同样的需要在部署、测试和监控方面做很多的工作，还需要考虑如何扩展系统，并保证它们的弹性，以及分布式事务等问题
演化式架构师
“事实上，我们要创造的东西从设计上来说就是要足够的灵活，有更好的适应性，并且能够根据用户的需求进行演化”
架构师必须改变那种从一开始就要设计出完美产品的想法，相反我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统，并且一旦我们学到了更多知识，应该可以很容易地应用到系统中。
像是城市规划师，而不是建筑师
作为架构师，不应该过多关注每个区域内发生的事情。这意味着我们应该考虑不同的服务之间如何交互，或者说保证我们能够对整个系统的健康状态进行监控。
制定原则，并且原则与实践相结合，用一些重要的原则来指导系统的演化，以及如何实现这些原则的细节。
- 例如通信的方式，不能一个是http接口，一个是protobuffer，另一个又是Java RMI
- 代码规范
- 日志处理
能够清晰地描绘出跨服务系统的健康状态非常关键
可以选择push或者pull的方法进行收集数据，日志与监控类似，都是需要集中式管理
做好技术债务的平衡
一个演进式架构师应该承担的职责
- 愿景: 确保在系统级有一个经过充分沟通的技术愿景，这个愿景可以帮助你满足客户和组织的需求
- 同理心: 理解你所做的决定对客户和同事带来的影响
- 合作: 和尽量多的同事进行沟通，从而更好地对愿景进行定义、修订及执行
- 适应性: 确保在你的客户和组织需要的时候调整技术愿景
- 自治性: 在标准化和团队自治之间寻找一个正确的平衡点
- 治理: 确保系统按照技术愿景的要求实现