第二章 演化式架构师

不准确的比较

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

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

架构师的演化视角

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

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

分区

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

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

一个原则性的方法

战略目标

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

原则

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

例子：

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

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

原则最好不要超过10个。

Heroku的12 Factors

The Twelve-Factor App

实践

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

真实例子

要求的标准

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

监控

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

接口

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

架构安全性

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

代码治理

范例

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

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

裁剪服务代码模板

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

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

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

小结

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

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

文章知识点与官方知识档案匹配，可进一步学习相关知识云原生入门技能树服务 格(istio)ServiceMesh介绍8967 人正在系统学习中