读【微服务设计】（二）领导者要考虑的事

1. 监控

能够清晰的描绘出跨服务系统的健康状态非常重要，这必须在系统级别而非单个服务级别进行考虑。往往在需要诊断一个跨服务的问题或者想要了解更大的趋势时，你才需要知道每个服务的健康状态。

简单起见，作者建议确保所有服务都是用相同的方式报告健康状态及其它监控相关的指标数据。

2. 统一服务接口技术

选择少数几种（甚至一种）明确的接口技术有助于新消费者的集成。

3. 架构安全性

一个运行异常的服务可能毁了整个系统，我们需要保证每个服务能够应对上游服务的错误响应。

这通常需要引入一个断路器，而断路器根据一定的规则来运行，需要我们制定一些固定的规则；比如让断路器根据HTTP返回码来工作，那上游服务就必须按照HTTP状态码的语义来返回状态码，不能混用4xx和5xx。一般我们需要对以下几种请求情况做不同处理：

• 正常响应，并且正确处理。
• 正常响应，但被服务识别出是错误请求。
• 响应超时，目标服务宕机。

4. 代码治理

聚在一起，就如何做事情达成共识是一个好主意。但是，花时间保证人们按照这个共识来做事情就没那么有趣了，因为在各个服务中使用标准做法会成为开发人员的负担。所以至少应该做到以下几点：提供范例和服务代码模板。

提供范例是很用的，无论你是通过可运行的代码还是文档形式提供。如果你有一些很好的实践希望别人采纳，那么给出一系列的代码范例会很有帮助，这可以帮助他们快速模仿，而且不会错的太离谱。

提供服务代码模板。当开发人员想要创建一个新服务时，所有实现基本功能的代码都应该是现成的，开发人员能够复制模板进而快速编写业务代码。

针对自己的开发实践裁剪出一个服务代码模板，不但可以提高开发速度，还可以保证服务质量，团队需要保持模板的更新。

5. 团队也应该拥有自治性

作者说到：每个组织都是不同的，他合作过的某些公司有高度自治的团队，能够得到公司的充分信任，对于这种情况，原则都是很轻量级的。但部分公司的组织结构化较强，开发人员拥有较小的自由度，这个时候需要【例外管理】来保证规则的合理性。

我理解的作者这里的态度是：架构师或技术主管不应该对开发人员有过多的限制，因为这也会限制现有架构/原则的合理性。

6. 集中治理和领导

微服务架构的领导者（架构师或技术主管）的一部分职责是治理。什么是治理：

治理通过评估干系人的需求、当前情况及下一步的可能性来确保企业目标的达成，通过排优先级和做决策来设定方向。

对已经达成一致的方向和目标进行监督。

领导者的一些职责：

• 确保有一个技术愿景，而治理就是要确保我们构建的系统符合这个愿景，在需要的时候对愿景进行演化。
• 确保有一个可以指导开发的原则，且以这些指导原则衍生出来的实践不会给开发人员带来痛苦。
• 需要不断的了解新技术，指导什么时候做怎样的取舍（也就是（原则/愿景的）演化）。
• 让开发同事也理解这些决策和取舍，并执行下去。
• 需要和团队一起工作，甚至是编码，从而了解到所做的决策对团队造成了怎样的影响。

一般来说，治理是一个小组活动，它可以是与一个小团队进行非正式聊天，也可以是在比较大的范围内，与一个有正式成员的小组进行正式例会，在这些会议上，可以讨论前面提到的原则，有必要的话也可以进行修改。当然，会议应该由技术专家领导，并且要有一线开发人员的参与。整个小组应该持续负责跟踪和管理技术风险。

有时候领导者可能不认同小组做出的决定，这时候应该怎么办？作者提到，大多数时候他都是认同小组的决定，因为一个小组通常比单个人更加聪明，而且你给一个小组权力去做决定，但最后忽略了这个决定，那小组就毫无意义了。

必要的时候，领导者需要对小组施加影响，领导需要指定什么时候可以做什么，不能做什么，这是很关键的。

7. 建设团队

引用作者原话：

对于一个系统技术愿景的主要负责人来说，执行愿景不仅仅等同于做技术决定，和你一起工作的那些人自然会做这些决定。

对于技术领导人来说，更重要的事情是帮助你的队友成长，帮助他们理解这个愿景，并保证他们可以积极地参与到愿景的实现和调整中来。

在单应用系统中，开发人员为某些事情负责的机会十分有限，而在微服务架构中存在多个自治的代码库，每个代码库都有着自己独立的声明周期，这就给更多人提供了对单个服务负责的机会，而当这些人在单个服务上面得到足够锻炼之后，就可以给他们更多的责任，从而帮助他们逐步达成自己的职业目标，同时通过分担职责也可以防止某一个人的负担过重。

我坚定地相信，伟大的软件来自于伟大的人，所以如果你只担心技术问题，那么恐怕你看到的问题远远不及一半。