读《微服务设计》

WHY:微服务架构可以更快的交付软件,有更多机会尝试新技术。技术决策上有极大的自由度。软件更新可以很频繁。

WHAT:一个微服务就是一个独立的实体,专注于做好一件事。可以独立部署在paas平台。服务之间通过API进行通信,避免紧耦合。因此需要考虑好什么应该暴露,什么应该隐藏。

HOW微?一个微服务应该可以在两周内完全重写。或者你不认为代码库过大。

核心原则:高内聚低耦合。

好的微服务:限界上下文寻找技术接缝,将微服务与这些技术边界相匹配。

弊:管理大量微服务会复杂。需要一个“架构师”来确保团队有共同的技术愿景。

正告1:如果想要得到一条通用准则,微服务是一个错误的选择。

正告2:走捷径会引人技术债务。


如果使用客户端方式,千万不要把与目标服务相关的逻辑放到客户端库中。

每个微服务都有各自的源代码库和CI构建。

当发现脆弱的测试时,应该竭尽全力去解决这个问题。否则,我们对出错会变得习以为常。当不能立即修复时,需要把他们记录下来(比如提个ec),并从测试套间中移除。

实际上,有些不必要的测试可以被删掉。删除测试往往令人担忧,这可以理解。但这样可以避免每个故事都端到端交付导致大量重发测试用例,使得测试库臃肿,反馈周期太长的缺点。当然,这里也是从周期时间和低风险之间做取舍。

赋予团队更多的服务所有权,会提高自治和交付速度,激励团队创建易于部署的服务。大面积采用特性团队后,容易出现很少有人下意识的做守护者。

服务相当成熟很少改变的时候,才是开源让别人贡献代码的时候。

你可能感兴趣的:(读《微服务设计》)