架构师的一个重要职责是，确保团队有共同的技术愿景，以帮助我们向客户交付他们想要的系统。
对于我们创造的大多数产品来说，交付到客户手里之后，还是要响应客户的变更需求，而不是简单的交给客户一个一成不变的软件包。
因此，架构师必须改变那种从一开始就要设计出完美产品的想法，相反我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统，
并且一旦我们学到了更多知识，应该可以很容易的应用到系统中。
当用户对软件提出变更需求时，我们需要对其进行响应并作出相应的改变。未来的变化很难预测，所以与其对所有变化的可能性进行预测，不如做一个允许变化的计划。
架构师的职责之一就是保证系统适合开发人员在其上工作。
下图是，原则和实践的真实例子
监控
能够清晰的描述跨服务系统的健康状态非常关键。
日志功能和监控情况类似：也需要集中式管理。
接口
选用少数几种明确的接口技术有助于新消费者的集成。
架构安全性
一个运行异常的服务可能会毁了整个系统，而这种后果是我们无法承担的，所以，必须保证每个服务都可以应对下游服务的错误请求。
你可以至少让每个下游服务使用它们自己的连接池，进一步让每个服务使用一个断路器。
代码治理
两种比较奏效的方法是，提供范例和服务代码模板。
范例
编写文档是有用的。但是开发人员更喜欢可以查看和运行代码。
理想情况下，你提供的优秀范例应该来自真实项目，而不是专门实现的一个完美的例子。因为如果你的范例来自真正运行的代码，
那么久可以保证其中所体现的那些原则都是合理的。
裁剪服务代码模板
针对自己的开发实践裁剪出一个服务代码模板，不但可以提高开发速度，还可以保证服务的质量。
技术债务
有时候可能无法完全遵守技术愿景，比如为了发布一些紧急的特性，你可能会忽略一些约束。其实这仅仅是另一个需要做的取舍而已。
我们的技术愿景有其本身的道理，所以偏离这个愿景短期可能会带来利益，但是长期来看是要付出代价的。这里用技术债务这个概念帮助我们理解这个取舍。
架构师的职责就是从更高的层次出发，理解如何做权衡。理解债务的层次及其对系统的影响非常重要。
例外管理
原则和实践可以指导我们如何构建系统。那么，如果系统偏离了这些指导又会发生什么呢？
有时候我们会决定针对某个规则破一次例，然后把它记录下来。如果这样的例外出现了很多次，就可以通过修改原则和实践的方式把我们的理解固化下来。
总结
一个演进的架构师赢狗承担的职责。
- 愿景 ： 确保在系统级有一个经过充分沟通的技术愿景，这个愿景应该可以帮助你满足客户和组织的需求
- 同理心 ： 理解你所做的决定对客户和同事带来的影响
- 合作 ： 和尽量多的同事进行沟通，从而更好的对愿景进行定义、修订及执行
- 适应性 ： 确保在你的客户和组织需要的时候调整技术愿景
- 自治性 ： 在标准化和团队自治之间寻找一个正确的平衡点
- 治理 ： 确保愿景按照技术愿景的要求实现
演进式架构师应该理解，成功要靠不断的取舍来实现。总会存在一些原因需要你改变工作的方式，但是具体做哪些改变就只能依赖于自己的经验了。
而僵化的固守自己的想法无疑是最糟糕的做法。
在微服务系统中，架构师需要做更多的决定，因此，能更好的平衡这些取舍是非常关键的。