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

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

 

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

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

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

 

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

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

 

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

 

监控

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

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

接口

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

架构安全性

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

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

代码治理

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

范例

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

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

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

 

裁剪服务代码模板

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

技术债务

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

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

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

例外管理

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

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

 

总结

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

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

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

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

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

 

posted @ 2019-08-14 23:55  Vincent-yuan  阅读(212)  评论(0编辑  收藏  举报