微服务设计 第二章 笔记

第二章 演化式架构师

不准确的比较

架构师的一个重要职责：确保团队有共同的技术愿景，以帮助我们向客户交付他们想要的系统。

**软件架构师和建筑师是天壤之别的！不要用建筑师的视角来看待软件开发。**建筑行业存在种种精确的约束，成果是一个“死”东西；而软件开发创造的东西从设计上来说就是要足够灵活，有很好的适应性，并且能根据用户的需求进行演化。

架构师的演化视角

架构师必须改变那种从一开始就要设计出完美产品的想法，相反我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统，并且一旦我们学到了更多的知识，应该可以很容易地应用到系统中。

架构师应该专注在大方向上，只在很有限地情况下参与到非常具体地细节实现中来。需要保证系统不但能够满足当前的需求，还能够应对将来的变化。

分区

架构师不应过多关注每个区域内发生的事，而应该多关注区域之间的事。

架构师需要花时间和团队在一起工作，应该和团队真正坐在一起。

一个原则性的方法

战略目标

通常我们不需要定义战略目标，这些战略目标的层次一般都很高，而且一般不会涉及技术这个层面。

原则

为了符合战略目标，我们会制定一些具体的规则，称之为原则，它不是一成不变的。

例子：

战略目标：在其它国家快速增长业务。

原则：整个系统必须能够方便地部署到相应的国家。

原则最好不要超过10个。

Heroku的12 Factors

The Twelve-Factor App

实践

通过相应的实践来保证原则能够得到实施，这些实践能够指导我们如何完成任务。通常这些实践是技术相关的，而且是比较底层的。比如代码规范、日志数据集中捕获等等。

真实例子

要求的标准

系统应该由很多小的但有自治生命周期的组件构成，而且这些组件之间有着紧密的关联。所以在优化单个服务自治性的同时，也要兼顾全局。一种能帮助我们实现平衡的方法就是，清除地定义出一个好服务应有的属性。

监控

建议确保所有的服务使用同样的方式报告健康状态及其与监控相关的数据，保持标准化。

接口

选用少数几种明确的接口技术有助于新消费者的集成。

架构安全性

必须保证每个服务都可以应对下游服务的错误请求。

代码治理

范例

编写文档是很有用的，但开发人员更喜欢可以查看和运行的代码。

理想情况下，提供的优秀范例应该来自真实项目，而不是一个专门实现的完美例子。

裁剪服务代码模板

如何能够让所有的开发人员很容易地遵守大部分的指导原则？

一种可能的方式：当开发人员想要实现一个新服务时，所有实现核心属性的那些代码都应该是现成的，针对自己的开发实践裁剪出一个服务代码模板。

应该可以选择是否使用服务代码模板，但是如果强制团队使用它，一定要确保是简化工作，而不是使其复杂化。

小结

一个演进式架构师应该承担的职责：

• 愿景：确保在系统级有一个经过充分沟通的技术愿景，这个愿景应该可以帮助你满足客户和组织的需求。
• 同理心：理解所做的决定对客户和同事带来的影响。
• 合作
• 适应性：确保在你的客户和组织需要的时候调整技术愿景。
• 自治性：在标准化和团队自治之间寻找一个正确的平衡点。
• 治理：确保系统按照技术愿景的要求实现。