演化式架构师:
2.1 不准确的比较
架构师的一个重要职责是,确保团队有共同的技术远景,以帮助我们向客户提供他们想要的系统。
2.2 架构师的演化视角
架构师必须改变那种从一开始就要设计出完美产品的想法,相反我们应该设计一个合理的框架,在这个框架下可以慢慢演化出正确的系统。
2.3 分区
区域对应的是服务的边界,我们不应该过多的关注每个区域内发生的事情,而应该多关注区域之间的事情。这意味着我们应该考虑不同的服务
之间如何交互,或者说保证我们能够对整个系统的健康状态进行监控。
2.4 一个原则性的方法
1.战略目标
战略目标关心的是公司的走向,如果你是制定公司技术远景的人,那么你可能需要花费更多的时间和组织内非技术的部分(业务部门)进行交互。
2.原则
为了和更大的目标保持一致,我们会制定一些具体的规则,并称之为原则。
3.实践
我们通过相应的实践来保证原则能够得到实施,这些实践能够指到我们如何完成任务。实践应该巩固原则。
4.将原则和实践相结合
要有一些重要的原则来指到系统的演化,同时也要有一些细节来指到如何实现这些原则。
5.真实世界的例子
2.5 要求的标准
1.监控
能够清楚的描绘出服务系统的健康状态非常关键。这必须在系统级别而非单个服务级别进行考虑。所有的服务使用同样的方式报告健康状态及其监控
相关的数据。Graphite,Nagios
2.接口
选用少数几种明确的接口技术有助于新消费者的集成。
3.架构安全性
一个运行异常的服务可能会毁了整个系统,所以,必须保证每个服务都可以应对下游服务的错误请求。你可以至少让每个下游服务使用它们自己的连接池,
进而让每个服务使用一个熔断器。
返回码也应该遵守一定的规则。如果你的熔断器依赖于 http 返回码,并且一个服务决定用 2xx 作为错误码,或者把 4xx 和 5xx 混用。那么这种安全措施
就没什么意义了。即使你使用的是 http,也应该注意类似的问题。对以下几种请求做不同的处理可以帮助系统即时失败,并且也很容易追溯 :
1.正常并且被正确处理的请求;
2.错误请求,并且服务识别出了它是错误的,但什么都没做
3.被访问的服务宕机了,所以无法判断请求是否正常
2.6 代码治理
提供范例和服务代码模板
2.7 技术债务
技术愿景有其本身的道理,所以偏离这个愿景短期可能会带来利益,但是长期看要付出代价的。这就是技术债务。
不光走捷径会引入技术债务,有时候系统的目标发生变化,并且与现有的实现不符,也会产生技术债务。
架构师的职责就是从更高的层次出发,理解如何做权衡。理解债务的层次及其对系统的影响非常重要。
2.8 例外管理
2.9 集中治理和领导
架构师的部分职责是治理:
治理通过评估干系人的需求,当前情况以及下一步的可能性来确保企业目的的达成,通过排优先级和做决策来设定方向。对已经达成一致的方向和
目标进行监督。
如果说,架构师的一个职责是确保有一个技术愿景,那么治理就是要确保我们构建的系统符合这个愿景,而且在需要的时候应该对愿景进行演化。
架构师会对很多事情负责。他们需要确保有一组可以指导开发的原则,并且这些原则要与组织的战略相符。他们还需要确保,以这些原则为指到衍生出来的
的实践不会给开发人员带来痛苦。他们需要了解新技术,需要知道在什么时候做怎样的取舍。他们不应该独自坐这些事情,可以由一个治理小组做这个工作。
治理是一个小组活动。它可以是一个足够小的团队进行非正式聊天,也可以是比较大的范围,与一个有着正式成员的小组进行结构化的例会。由技术专家领导,
并且要有一线人员参与。这个小组也应该负责跟踪和管理技术风险。
架构师领导这个小组,但是每个交付团队的人都要参与。架构师确保该组织正常运行,整个小组都要对治理负责。这样职责就得到了分担,并且保证有来自高层
的支持,这样也可以确保信息从开发团队顺畅的流入这个小组。
类比教小朋友骑自行车的过程,你没办法替代他们去骑自行车。不能每次摇摇晃晃就去扶一把,但是如果他们驶入车流繁忙的大马路,你就必须站出来了。
2.10 建设团队
对于一个系统技术愿景的主要负责人来说,执行愿景不仅仅等同于做技术决定,和你一起工作的那些人自然会做这些决定。对技术领导人来说,更重要的是帮助
你的队友成长,帮助他们理解这个愿景,并且保证他们可以积极的参与到愿景的实现和调整中来。
微服务架构本身是一个很好的提供形式,在单块系统中,人们为某些事情负责的机会非常有限,而微服务中存在很多自治的代码库,每个代码库都有自己独立的
生命周期,这就给了更多人对单个服务负责的机会。而这些人在单个服务上面得到锻炼之后,就可以给与更多任务,帮助他们达成职业目标,同时通过分担职责也可以
防止某一个人的负责过重。
2.1 不准确的比较
2.2 架构师的演化视角
2.3 分区
2.5 要求的标准
2.6 代码治理
2.8 例外管理
2.9 集中治理和领导
2.10 建设团队