网站架构师的工作内容( 架构师的含义与你想表达的意思并不一样?)

优采云 发布时间: 2022-01-07 18:11

  网站架构师的工作内容(

架构师的含义与你想表达的意思并不一样?)

  建筑师的真正职责

  “你总是提到的这个词的意思和你想表达的不一样。”——伊尼戈·蒙托亚,电影《公主与新娘》中的人物

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

  在某些场景中,架构师只需要和一个团队一起工作,此时他们就相当于技术领导者。在其他情况下,他们负责整个项目的技术愿景,通常需要协调多个团队甚至整个组织之间的工作。

  无论您处于什么级别,架构师的角色都非常微妙。在一般的组织中,非常优秀的开发人员可以成为架构师,但他们通常比其他角色受到更多的批评。

  与其他角色相比,架构师在很多方面都有更直接的影响,比如正在构建的系统的质量、同事的工作条件以及组织应对变化的能力。这个角色也很难做好,是什么原因?

  很多时候人们似乎忘记了我们的行业还很年轻。我们编写的程序运行在计算机上,而计算机只有 70 年的历史,因此我们需要不断地在现有行业中搜索,以帮助其他人了解我们的工作。

  我们不是医生或医学工程师,也不是水管工或电工。我们处于这些行业的中间,所以社会很难理解我们,我们不知道我们在哪里。

  所以我们尝试向其他行业学习。我们称自己为软件“工程师”或“架构师”1,但实际上我们不是,对吗?

  建筑师和工程师的精确度和纪律是遥不可及的,他们在社会中的重要性很容易理解。

  我的一个朋友在成为注册建筑师的前一天说:“如果明天我在酒吧里给你错误的建房子的建议,那么我将负责。从法律的角度来看,因为我是一个认证建筑师。建筑师,所以如果你犯了错误,你可能会被起诉。”

  他们在社会中扮演着非常重要的角色,所以他们需要获得特别的认证才能工作。例如,你需要在英国学习至少七年才能成为一名建筑师。这些职业在几千年前就存在了,但我们呢?真是天壤之别。

  这就是为什么我觉得很多形式的IT证书一文不值,因为我们对什么是好的知之甚少。

  有些人想要得到社会的认可,就借用了这些行业内已经被大众认可的名词,但这可能会造成两个问题。

  首先,这样做的前提是我们要清楚自己应该做什么,而在大多数情况下并非如此。不是建筑物和桥梁不会倒塌,而是它们倒塌的频率远低于我们程序倒塌的频率,因此将它们与工程师进行比较是不公平的。

  其次,经过一些粗略的观察,你会发现这个比喻是站不住脚的。因为如果桥梁施工和编程类似,那么在施工中途,你可能会发现对岸比预期的远了50米,材料是花岗岩而不是泥土。更糟糕的是,我们最终想要一座公路桥。而不是人行天桥。

  该软件在物理规则方面没有真正的工程师和建筑师的约束。其实我们想要创造的东西,设计得足够灵活,适应性好,能够根据用户的需求去执行。进化。

  也许“建筑师”这个词很有问题。架构师的工作就是制定一个详细的计划,然后让别人理解并执行。

  开展这项工作需要艺术性和工程性之间的平衡,以及整体的监督,其他所有的视角都必须从属于建筑师的视角,当然,有时他们也会根据建筑的物理规则考虑一些建议。结构工程师。

  在我们的行业中,这种架构师的观点可能会导致一些非常糟糕的做法。人们试图通过大量的图表和文档来创建一个完美的解决方案,而忽略了许多基本的未知因素。

  使用这种方法会让人难以真正理解实现的难度,或者即使设计可行,在对系统了解更多之后更不可能修改设计。

  当我们将自己与工程师或建筑师进行比较时,我们很可能会做出错误的决定。不幸的是,建筑师这个词已经被大众接受了,所以我们现在能做的就是在上下文中重新定义这个词的含义。

  本文摘自《微服务设计》

  建筑师的进化视角

  与建造建筑物相比,我们在软件上会面临大量的需求变化,使用的工具和技术也多种多样。

  我们创造的东西在某个时间点后不会停止变化,即使发布到生产环境后,软件也可以继续发展。

  对于我们创造的大部分产品,在交付给客户之后,我们仍然要响应客户不断变化的需求,而不是简单地将一个固定的软件包交给客户。

  因此,建筑师必须从一开始就改变设计完美产品的想法。相反,我们应该设计一个合理的框架,在这个框架下我们可以慢慢进化出正确的系统,并且一旦我们了解更多,应该很容易应用到系统中。

  虽然到目前为止,本章已经警告你不要和其他行业做太多比较,但我发现有一个角色可以比 IT 架构师更好。

  这个想法是 Erik Doernenburg 告诉我的,他认为更好的类比是城市规划师,而不是建筑师。如果你玩过模拟城市,那么你应该熟悉城市规划师这个角色。

  城市规划者的职责是优化城镇布局,让现有居民更容易居住,同时还要考虑一些未来的因素。为了实现这个目标,他需要采集各种信息。

  规划师影响城市演变的方法很有意思。他不会直接说“在那个地方建造这样的建筑物”。相反,他将分割城市。

  就像在模拟城市中,你可以将城市的某一部分规划为工业区,将另一部分规划为住宅区,然后其他人将决定建造什么建筑物。当然,这个决定会受到一定的限制。例如,工厂必须建在工业区。

  城市规划者更多地考虑人和公共设施如何从一个区域移动到另一个区域,而不是每个区域会发生什么。

  许多人将城市比作生物,因为城市会不时发生变化。当居民对城市的使用发生变化或受到外力影响时,城市也会随之发生变化。城市规划者应该尽量预测可能发生的变化,但他们也需要明白,试图直接控制各个方面往往是行不通的。

  小镇和上面描述的软件之间的对应关系应该是显而易见的。当用户对软件进行更改时,我们需要对其做出响应并做出相应的更改。

  未来的变化很难预见,所以与其预测所有变化的可能性,不如制定一个允许变化的计划。因此,您应该避免对所有内容进行过于详细的设计。城市系统应该让生活在其中的居民感到幸福。

  经常被忽视的一件事是,系统的用户不仅是最终用户,还包括在其上工作的开发人员和运维人员。他们还负责系统需求的变化。

  借用 Frank Buschmann 的说法:架构师的职责之一是确保系统适合开发人员工作。

  城市规划师就像建筑师,他需要知道他的计划何时尚未实施。虽然他会少出台一些规定,尽量少纠正发展方向,但如果有人决定在居民区建一个污水池,他应该可以阻止。

  因此,我们的建筑师应该像城市规划师一样专注于大方向,只在非常有限的情况下参与非常具体的细节。他们需要确保系统不仅能够满足当前的需求,而且能够应对未来的变化。

  他们应该确保在系统上工作的开发人员和使用系统的用户一样快乐。这听起来是一个非常高的标准,那么你从哪里开始呢?

  划分

  早些时候,我们将建筑师比作城市规划师。那么在这个比喻中,区域的概念对应什么?它们应该是我们的服务边界,或者一些粗粒度的服务组。

  作为架构师,你不应该过多关注每个区域发生的事情,而应该更多地关注区域之间的事情。这意味着我们应该考虑不同服务如何交互,或者确保我们可以监控整个系统的健康状况。

  至于参与地区内政的程度,因情况不同而有所差异。许多组织采用微服务来最大化团队的自主权。第 10 章将更多地讨论这个话题。如果您在这样的组织中,那么您将更多地依赖团队来做出正确的部分决策。

  但是区域之间,或者传统架构图中的框图之间,我们需要非常小心,因为在这些地方犯的错误将很难纠正。

  每个服务都可以让团队选择不同的技术堆栈或数据存储技术。当然,还需要考虑其他问题。

  但实际上,团队不会无限制地选择任何技术堆栈。比如你需要支持10个不同的技术栈,你可能会遇到招聘困难,或者不同团队之间人员交流困难。

  同样,如果每个团队自己选择完全不同的存储技术,您可能会发现自己对它们还不够熟悉。

  例如,Netflix 对 Cassandra 存储技术有非常成熟的使用规范,并且认为围绕 Cassandra 构建相关工具和培养专家比针对特定任务使用最合适的技术更重要。

  Netflix 就是一个极端的例子。他们认为可扩展性是最重要的因素,但是你可以通过这个例子有自己的理解。

  但是,服务之间的事情可能会变得非常糟糕。如果一个服务决定通过 HTTP 暴露 REST 接口,另一个使用协议缓冲区,第三个使用 Java RMI,那么作为服务消费者,它需要支持各种形式的交互,这对于消费者来说简直就是一场噩梦。

  这就是为什么我强调我们应该“担心服务之间的交互,而不需要过多关注每个服务内部发生的事情”。

  如果代码架构师想要确保我们创建的系统对开发人员足够友好,那么架构师需要了解他们的决定将如何影响系统。最低要求是:架构师需要花时间与团队合作,理想情况下他们应该一起编码。对于实施结对编程的团队,架构师很容易花一定的时间与团队成员结对。理想情况下,你应该参与到普通的工作中,这样你才能真正了解什么是普通的工作。架构师和团队真的是坐在一起,这件事怎么强调都不为过!相比通过电话沟通或者只是看团队的代码,这种与团队合作的方式更有效。至于与团队合作的频率取决于团队的规模,关键是它必须成为日常工作的一部分。如果你和四个团队一起工作,每四个星期和每个团队一起工作半天,可以帮助你与团队有效沟通,了解他们都在做什么。

  有原则的方法

  “规则是智者的指导方针,愚蠢者的服从。”——一般认为来自道格拉斯·巴德(Douglas Bader)

  在做出系统设计决策时,您通常会进行权衡。在微服务架构中,您必须做出许多权衡!

  在选择数据存储技术时,你会选择一种不太熟悉但可以带来更好扩展性的技术吗?系统中有两个技术栈是否可以接受?那三个呢?

  做出某些决定所需的信息很容易获得,这相当容易。但是决策所需的一些信息很难获得,那我们该怎么办?

  根据要实现的目标定义一些原则和实践对设计非常有利。让我们接下来讨论它们。

  1. 战略目标

  做架构师已经很辛苦了,不过还好,通常我们不需要定义战略目标!战略目标与公司的方向以及如何让客户满意有关。

  这些战略目标的层次一般都很高,但通常不涉及技术层面,一般只在公司或部门层面制定。这些目标可以是“开拓*敏*感*词*新市场”或“尽可能让用户使用自助服务”。因为这些是您的组织前进的方向,所以您需要确保技术选择与其一致。

  如果您是设定公司技术愿景的人,那么您可能需要花更多时间与组织的非技术部分(通常称为业务部门)进行互动。那么业务部门的愿景是什么?它将如何改变?

  2. 原则

  为了与更大的目标保持一致,我们会制定一些具体的规则并称之为原则,这些规则不是一成不变的。

  例如,如果一个组织的战略目标是缩短新功能上线的时间,那么一个可能的原则是交付团队应该完全控制整个软件生命周期,以便他们能够及时交付任何准备好的功能。不受其他球队的限制。

  如果该组织的另一个目标是在其他国家快速发展业务,那么您需要使用的原则可能是整个系统必须轻松部署到相应国家,以满足该国家对数据存储地理位置的要求。

  这些原则可能不适合您的组织。一般来说,最好不要超过10条原则,或者可以写在海报上,否则大家很难记住。原则越多,它们就越有可能重叠和冲突。

  Heroku 的 12 Factors 是一组设计原则,可以帮助您在 Heroku 平台上创建应用程序,当然它们在其他上下文中也可能有用。其中,有些原则其实是为了让你的应用能够适应Heroku平台引入的约束。

  约束很难(或不可能)改变,但原则也由我们决定。你应该明确指出哪些是原则,哪些是约束,以便用户知道哪些是不能改变的。从个人的角度来看,我认为将原则和约束放在同一个列表中是好的,这样我们就可以不时审查这些约束是否真的不可变。

  3. 练习

  我们确保这些原则可以通过相应的实践得到落实,这些实践可以指导我们如何完成任务。

  通常这些做法都是技术相关的,比较低级,所以任何开发者都可以理解。这些实践包括代码规范、日志数据的集中捕获或作为标准集成样式的 HTTP/REST。由于实践更具有技术性,因此更改的频率会高于原理。

  就像原则一样,有时实践也反映了组织内部的一些局限性。比如你只支持CentOS,那么相应的做法就应该考虑这个因素。

  实践要巩固原则。例如,我们提到了一个原则,即开发团队应该能够控制整个软件开发过程。相应的做法是将所有服务部署在不同的AWS账户中,从而提供资源的自助管理和与其他团队的隔离。.

  4. 原则与实践相结合

  有些事情对某些人来说是原则,对另一些人来说是实践。例如,您可能会使用 HTTP/REST 作为原则而不是实践。

  这不是问题,关键是要有一些重要的原则来指导系统的演进,还要有一些细节来指导如何执行这些原则。

  对于一个足够小的团队,比如一个团队,原则和实践相结合是可以的。但是在一个大的组织中,技术和工作实践可能不同,不同地方所需的实践也可能不同。

  不过没关系,只要能全部映射到同一个原理就可以了。例如,.NET 团队可能有一套实践,Java 团队可能有另一套实践,但它们背后的原则是相同的。

  5. 真实世界的例子

  我的同事 Evan Bottcher 帮助客户绘制了图 1 所示的图表。该图表清楚地显示了目标、原则和实践之间的相互作用。

  这几年,实践变化频繁,但原则变化不大。您可以打印出这样的图表并与相关人员共享。其中的每一项都非常简单,因此开发人员应该很容易记住它们。

  虽然每个练习背后都有很多细节,但总结一下还是很有用的。

  

  图 1:原则和实践的真实例子

  上面提到的一些项目可以通过文档来支持,但在大多数情况下,我喜欢给出一些示例代码供人们阅读、学习和运行,以传达上面涉及的信息。更好的方法是创建一些工具来确保我们所做的正确性。很快就会有关于这个话题的深入讨论。

  所需标准

  当您浏览这些实践并考虑您需要做出的权衡时,有一个非常重要的因素需要注意:系统允许多少可变性。

  我们需要确定每个服务需要遵守的一般规则。一种方法是举一个好服务的例子来说明好服务的特点。什么是制度中好的服务“公民”?

  需要什么样的能力才能保证整个系统可控,一个有问题的服务不会导致整个系统瘫痪?

  这些问题都很难回答,因为就像人一样,在某个情境下做一个好公民并不意味着在其他情境下你就是一个好公民,但我们仍然可以在各种服务中观察到一些常见的良好做法。一些关键领域的变化太多,这会导致很多问题。

  正如 Netflix 的 Ben Christensen 所说,当我们考虑更大的全景时,“系统应该由许多小而自主的生命周期组件组成,而这些组件是密切相关的。”

  因此,在优化单个服务的自治性的同时,也必须考虑全局。帮助我们实现平衡的一种方法是明确定义良好服务的属性。

  1. 监控

  能够清晰地描绘出跨服务系统的健康状态是非常重要的。这必须在系统级别而不是在单个服务级别考虑。

  通常当你需要诊断一个跨服务的问题或者想了解一个更大的趋势时,你只需要知道每个服务的健康状态。

  为简单起见,我建议确保所有服务使用相同的方法来报告健康状态和监控相关数据。

  您可以选择使用推送机制,即每个服务主动将数据推送到一个中心位置。(作者《微服务设计》第八章)

  您可以使用 Graphite 采集指标数据,使用 Nagios 检查健康状态,或使用轮询系统采集各个节点的数据。

  但无论您的选择是什么,您都应该努力保持标准化。每个服务中的技术应该是对外界不透明的,并且不应该为服务的具体实现而改变监控系统。日志功能类似于监控情况:也需要集中管理。

  2. 接口

  选择一些清晰的界面技术将有助于新消费者的整合。使用一种标准方法很好,两种也不错,但是 20 种不同的集成技术太糟糕了。这不仅仅是关于接口的技术和协议。

  例如,如果您选择 HTTP/REST,您会在 URL 中使用动词还是名词?你将如何处理资源的分页?您将如何处理不同版本的 API?

  3. 架构安全

  一个异常运行的服务可能会毁了整个系统,这个后果超出了我们的责任。因此,我们必须确保每个服务都能响应来自下游服务的错误请求。不能很好地处理下游错误请求的服务越多,我们的系统就越容易受到攻击。

  你至少可以让每个下游服务使用自己的连接池,进一步让每个服务使用一个断路器。在第 11 章讨论可扩展微服务时,将更深入地讨论该主题。

  返回码也应该遵循一定的规则。如果您的断路器依赖于 HTTP 返回码,并且服务决定使用 2XX 作为错误码,或者混合使用 4XX 和 5XX,那么这种安全措施是没有意义的。

0 个评论

要回复文章请先登录注册


官方客服QQ群

微信人工客服

QQ人工客服


线