本文共 1521 字,大约阅读时间需要 5 分钟。
架构师职责确保我们的团队有共同的技术愿景,并向我们的客户交付他们想要的系统。需要协调多个团队,甚至整个组织内的工作。
1 城市规划师
其实架构师更像是城市规划师,需要做出一个允许变化的计划。
系统的使用者除了客户,还有开发人员与运维人员。所以,架构师要确保系统适合开发人员在其上进行开发工作。
架构师应该专注大方向,只在有限情况下,才参与到具体的实现细节中。保证这套系统,会让开发人员和客户一样开心。
2 服务边界
作为架构师,应该多关注服务边界之间发生的事。比如,不同的服务之间交互方式、监控整个系统的健康状况等等。
每个服务内部,允许团队选择不同的技术栈或数据存储技术。
3 规则
为了和目标保持一致,我们需要制定出一些规则。规则最好不要超过 10 个,这样大家才容易记得住。
通过规则来指定系统如何演化。还需要指导这些规则如何实践。
除了文档,还可以提供示例代码供人阅读、研究与运行。甚至可以创造出一些工具来确保这些规则能够被正确执行。
4 特性
4.1 监控
必须能够在系统级别,清晰地描绘出跨系统服务的健康状态。建议:让所有的服务都使用同样的方式来报告健康状态。
可以使用推送方式,让每个服务把状态数据推送到某个节点;也可以使用轮询方式,从各个服务节点,收集状态数据。无论哪一种方式,都应该保持一致。并且,每个服务内的技术细节,对外应该是不影响、不透明的。
4.2 接口协议
选择少数几种明确的接口协议,有利于使用者开发对接程序。还需要多多考虑,比如如何处理不同版本的 API?
4.3 安全性
确保每个服务都能够处理调用方所返回的错误信息。
5 代码管理
5.1 示例代码
因为开发人员更喜欢阅读与允许代码,所以提供示例代码以供模仿,是个好主意。
5.2 代码模板
依据优秀的开发实践,导出一些代码模板,不但可以提高开发效率,而且还可以保证服务质量。
如果组织内使用了不同的技术栈,那么每一种技术栈,都需要提供相应的代码模板。
可以通过合作的方式定义好这些模板,并根据需要及时更新。
6 破例
有时候,因为特殊情况,违背了初定的规则。首先,先记下来。如果发生了很多次,那么我们可以修改规则,来适应变化。
如果团队高度自治,那么这些规则只要把握好大方向即可。
7 管理
通过排优先级和做决策来设定目标,然后监督定好目标是否朝着良性方向发展。
架构师要确保有可以指导开发的规则,并且这些规则与组织的战略目标相一致。需要了解新技术,并知道如何在这些技术之间做取舍。还要让大家也理解这些取舍决定,并执行下去。还需要花时间与团队一同工作,甚至是编程。
组织讨论会,可以是与一个比较小的团队进行非正式沟通;也可以是与大团队进行正式沟通。讨论会必须要由技术专家领导,并要有一线员工参与。讨论的内容可以是之前说过的规则,以及跟踪和管理技术风险。架构师必须确保这些讨论会可以顺畅运转。
注意:即使架构师很清楚这样做是对的,然后为了避免团队偏离方向,不得不控制他们的行为。这有可能会破坏和团队的关系,让他们感觉没什么话语权。关键是知道什么时候可以这样做,什么时候不能这样做。
8 团队建设
架构师必须帮助团队成长,让他们理解团队目标,并积极地参与到这个目标实践中来。
机会成熟时,就可以给团队成员更多的责任,帮忙他们实现自己的职业目标。
架构师的职责总结如下:
- 在系统级别,输出经过充分沟通的技术愿景,通过它可以帮助我们满足客户和组织的需求。
- 了解所做出的决定,对客户和团队所带来的影响。
- 和尽可能多的人沟通交流,修订技术愿景。
- 根据客户以及组织需要,及时调整技术愿景。
- 在自治和约束之间,寻找出一个平衡点。
- 管理并监督系统朝着愿景的方向,稳步前行。
转载地址:https://deniro.blog.csdn.net/article/details/98446844 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!