WHY:微服务架构可以更快的交付软件，有更多机会尝试新技术。技术决策上有极大的自由度。软件更新可以很频繁。
WHAT:一个微服务就是一个独立的实体，专注于做好一件事。可以独立部署在paas平台。服务之间通过API进行通信，避免紧耦合。因此需要考虑好什么应该暴露，什么应该隐藏。
HOW微？一个微服务应该可以在两周内完全重写。或者你不认为代码库过大。
核心原则:高内聚低耦合。
好的微服务:限界上下文寻找技术接缝，将微服务与这些技术边界相匹配。
弊:管理大量微服务会复杂。需要一个“架构师”来确保团队有共同的技术愿景。
正告1:如果想要得到一条通用准则，微服务是一个错误的选择。
正告2:走捷径会引人技术债务。
如果使用客户端方式，千万不要把与目标服务相关的逻辑放到客户端库中。
每个微服务都有各自的源代码库和CI构建。
当发现脆弱的测试时，应该竭尽全力去解决这个问题。否则，我们对出错会变得习以为常。当不能立即修复时，需要把他们记录下来（比如提个ec），并从测试套间中移除。
实际上，有些不必要的测试可以被删掉。删除测试往往令人担忧，这可以理解。但这样可以避免每个故事都端到端交付导致大量重发测试用例，使得测试库臃肿，反馈周期太长的缺点。当然，这里也是从周期时间和低风险之间做取舍。
赋予团队更多的服务所有权，会提高自治和交付速度，激励团队创建易于部署的服务。大面积采用特性团队后，容易出现很少有人下意识的做守护者。
服务相当成熟很少改变的时候，才是开源让别人贡献代码的时候。
