微服务之演化式架构师(二)

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

对于我们创造的大多数产品来说，交付到客户手里之后，还是要响应客户的变更需求，而不是简单的交给客户一个一成不变的软件包。

因此，架构师必须改变那种从一开始就要设计出完美产品的想法，相反我们应该设计出一个合理的框架，在这个框架下可以慢慢演化出正确的系统，

并且一旦我们学到了更多知识，应该可以很容易的应用到系统中。

当用户对软件提出变更需求时，我们需要对其进行响应并作出相应的改变。未来的变化很难预测，所以与其对所有变化的可能性进行预测，不如做一个允许变化的计划。

架构师的职责之一就是保证系统适合开发人员在其上工作。

下图是，原则和实践的真实例子

监控

能够清晰的描述跨服务系统的健康状态非常关键。

日志功能和监控情况类似：也需要集中式管理。

接口

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

架构安全性

一个运行异常的服务可能会毁了整个系统，而这种后果是我们无法承担的，所以，必须保证每个服务都可以应对下游服务的错误请求。

你可以至少让每个下游服务使用它们自己的连接池，进一步让每个服务使用一个断路器。

代码治理

两种比较奏效的方法是，提供范例和服务代码模板。

范例

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

理想情况下，你提供的优秀范例应该来自真实项目，而不是专门实现的一个完美的例子。因为如果你的范例来自真正运行的代码，

那么久可以保证其中所体现的那些原则都是合理的。

 

裁剪服务代码模板

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

技术债务

有时候可能无法完全遵守技术愿景，比如为了发布一些紧急的特性，你可能会忽略一些约束。其实这仅仅是另一个需要做的取舍而已。

我们的技术愿景有其本身的道理，所以偏离这个愿景短期可能会带来利益，但是长期来看是要付出代价的。这里用技术债务这个概念帮助我们理解这个取舍。

架构师的职责就是从更高的层次出发，理解如何做权衡。理解债务的层次及其对系统的影响非常重要。

例外管理

原则和实践可以指导我们如何构建系统。那么，如果系统偏离了这些指导又会发生什么呢？

有时候我们会决定针对某个规则破一次例，然后把它记录下来。如果这样的例外出现了很多次，就可以通过修改原则和实践的方式把我们的理解固化下来。

总结

一个演进的架构师赢狗承担的职责。

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

演进式架构师应该理解，成功要靠不断的取舍来实现。总会存在一些原因需要你改变工作的方式，但是具体做哪些改变就只能依赖于自己的经验了。

而僵化的固守自己的想法无疑是最糟糕的做法。

在微服务系统中，架构师需要做更多的决定，因此，能更好的平衡这些取舍是非常关键的。

原文：https://www.cnblogs.com/Vincent-yuan/p/11355501.html