必看！.NET 7 在网络领域的四大更新
Posted China soft
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了必看！.NET 7 在网络领域的四大更新相关的知识，希望对你有一定的参考价值。
http://www.pczh.cn/news/26036.html
最新的 .NET 7 现已发布，我们想介绍一下其在网络领域所做的一些有趣的更改和添加。这篇文章我们将讨论 .NET 7 在 HTTP 空间、新 QUIC API、网络安全和 WebSockets 方面的变化。
HTTP
改进了对连接尝试失败的处理
在 .NET 6 之前的版本中，如果连接池中没有立即可用的连接，（处理程序上的设置允许的情况下，例如 HTTP /1.1 中的 MaxConnectionsPerServer，或 HTTP/2 中的EnableMultipleHttp2Connections）新的 HTTP 请求始终会发起新的连接尝试并等待响应。这样做的缺点是，建立该连接需要一段时间，而在这段时间里如果另一个连接已经可用，该请求仍将继续等待它生成的连接，从而影响延迟。在 .NET 6.0 中我们改变了这一进程，无论是新建立的连接还是与此同时准备好处理请求的另一个连接，第一个可用的连接会处理请求。这样仍会一个新连接被建立（受限制），如果发起的请求未使用这一连接，则它会被合并以供后续请求使用。
不幸的是，.NET 6.0 中的这一功能对某些用户来说是有问题的：失败的连接尝试也会使位于请求队列顶部的请求失败，这可能会在某些情况下导致意外的请求失败。此外，如果由于某些原因（例如由于服务器行为不当或网络问题）池中有一个永远未被使用的连接，与之关联的新传入的请求也将延迟并可能超时。
在 .NET 7.0 中，我们实施了以下更改来解决这些问题：
- 失败的连接尝试只能使其相关的发起请求失败，而不会导致无关的请求失败。如果在连接失败时原始请求已得到处理，则连接失败将被忽略 ( dotnet/runtime#62935 )。
- 如果一个请求发起了一个新连接，但随后被池中的另一个连接处理，则新的待使用的连接尝试将不管 ConnectTimeout，在短时间后自动超时。通过此更改，延迟的连接将不会延迟不相关的请求 ( dotnet/runtime#71785 )。请注意，不被使用的连接尝试自动超时失败的这一进程只会在后台自己运行，用户不会看到此进程。观察它们的唯一方法是启用 telemetry。
HttpHeaders 读取线程安全
这些 HttpHeaders 集合从来都不是线程安全的。访问 header 可能会强制延迟解析它的值，从而导致对底层数据结构的修改。
在 .NET 6 之前，同时读取集合在大多数情况下恰好是线程安全的。
从 .NET 6 开始，由于内部不再需要锁定，针对 header 解析执行的锁定较少。这一变化导致许多用户错误地同时访问 header，例如，在 gRPC (dotnet/runtime#55898)、NewRelic (newrelic/newrelic-dotnet-agent#803)甚至 HttpClient 本身( dotnet/runtime #65379）。违反 .NET 6 中的线程安全可能会导致 header 值重复/格式错误或在枚举（enumeration）/header 访问期间产生各种异常。
.NET 7 使 header 行为更加直观。该 HttpHeaders 集合现在符合 Dictionary 线程安全保证：
集合可以同时支持多个读者，只要它不被修改。极少数情况下，枚举（enumeration）与书写访问权限争用，则该集合必须在整个枚举期间被锁定。要允许多个线程访问集合以同时进行读写，您必须实现自己的同步。
这是通过以下更改实现的：
- 无效值的“验证读取”不会删除无效值 – dotnet/runtime#67833（感谢@heathbm）。
- 同时读取是线程安全的——dotnet/runtime#68115。
检测 HTTP/2 和 HTTP/3 协议错误
HTTP/2 和 HTTP/3 协议在 RFC 7540 第 7 节和 RFC 9114 第 8.1节中定义了协议级别的错误代码，例如，HTTP/2 中的 REFUSED_STREAM (0x7) 或 HTTP/3 中的 H3_EXCESSIVE_LOAD (0x0107) 。与 HTTP 状态代码不同，这是对大多数 HttpClient 用户来说不重要的低级错误信息，但它在高级 HTTP/2 或 HTTP/3 场景中有帮助，特别是 grpc-dotnet，其中区分协议错误对于实现客户端重试至关重要。
我们定义了一个新的异常 HttpProtocolException 来在其 ErrorCode 属性中保存协议级错误代码。
HttpClient 直接调用时，HttpProtocolException 可以是内部异常HttpRequestException：
try
using var response = await httpClient.GetStringAsync(url);
catch (HttpRequestException ex) when (ex.InnerException is HttpProtocolException pex)
Console.WriteLine("HTTP error code: " + pex.ErrorCode)
使用 HttpContent 的响应流时，它被直接抛出：
using var response = await httpClient.GetAsync(url, HttpCompletionOption.ResponseHeadersRead);
using var responseStream = await response.Content.ReadAsStreamAsync();
try
await responseStream.ReadAsync(buffer);
catch (HttpProtocolException pex)
Console.WriteLine("HTTP error code: " + pex.ErrorCode)
HTTP/3
在 HttpClient 之前的 .NET 版本已经完成了对 HTTP/3 的支持，所以我们主要集中精力在这个领域的 System.Net.Quic 底层。尽管如此，我们确实在 .NET 7 中引入了一些修复和更改。
最重要的变化是现在默认启用 HTTP/3 ( dotnet/runtime#73153 )。这并不意味着从现在开始所有 HTTP 请求都将首选 HTTP/3，但在某些情况下它们可能会升级到HTTP/3。为此，请求必须通过将HttpRequestMessage.VersionPolicy设置为RequestVersionOrHigher，从而能够版本升级。然后，如果服务器在 Alt-Svc header 中有 HTTP/3 授权，HttpClient 将使用它进行进一步的请求，请参阅 RFC 9114 第 3.1.1 节。
QUIC
QUIC 是一种新的传输层协议。它最近已在 RFC 9000 中标准化。它使用 UDP 作为底层协议，并且它本质上是安全的，因为它要求使用 TLS 1.3。与众所周知的传输协议（如 TCP 和 UDP）的另一个有趣区别是它在传输层上内置了流多路复用。这使其能够拥有多个并发的独立数据流，且这些数据流不会相互影响。
QUIC 本身没有为交换的数据定义任何语义，因为它是一种传输协议。它更适用于应用层协议，例如 HTTP/3 或 SMB over QUIC。它还可以用于任何自定义协议。
与 TLS 的 TCP 相比，该协议具有许多优势。例如，它不需要像顶部带有 TLS 的 TCP 那样多的往返行程，所以能够更快地建立连接。它能够避免队头阻塞问题，一个丢失的数据包不会阻塞所有其他流的数据。另一方面，使用 QUIC 也有缺点。由于它是一个新协议，它的采用仍在增长并且是有限的。除此之外，QUIC 流量甚至可能被某些网络组件阻止。
.NET 中的 QUIC
我们在 System.Net.Quic 库中介绍了 .NET 5 中的 QUIC 实现。然而，到目前为止，这个库是仅限内部的，并且只为自己的 HTTP/3 实现服务。随着 .NET 7 的发布，我们公开了该库并公开了它的 API。由于我们只有 HttpClient 和 Kestrel 作为此版本 API 的使用者，因此我们决定将它们保留为预览功能。它使我们能够在确定最终形式之前在下一个版本中调整 API。
从实施的角度来看，System.Net.Quic 取决于 QUIC 协议的原生实现 MsQuic。因此，System.Net.Quic 平台支持和依赖项继承自 MsQuic，并记录在 HTTP/3 平台依赖项文档中。简而言之，MsQuic 库作为 .NET for Windows 的一部分提供。对于 Linux，libmsquic 必须通过适当的包管理器手动安装。对于其他平台，仍然可以手动构建 MsQuic，无论是针对 SChannel 还是 OpenSSL，并将其与 System.Net.Quic 一起使用。
API 概述
System.Net.Quic 携带了能够使用 QUIC 协议的三个主要类:
- QuicListener – 服务器端类，用于接受传入连接。
- QuicConnection – QUIC 连接，对应 RFC 9000 Section 5。
- QuicStream – QUIC 流，对应 RFC 9000 Section 2。
但是在使用这些类之前，用户代码应该检查当前系统是否支持 QUIC，因为系统可能缺失 libmsquic 或者不支持 TLS 1.3。为此, QuicListener 和 QuicConnection 都公开了一个静态属性 IsSupported:
if (QuicListener.IsSupported)
QuicListenerOptions
// Use QuicListener
else
// Fallback/Error
if (QuicConnection.IsSupported)
// Use QuicConnection
else
// Fallback/Error
请注意，目前这两个属性是同步的并将显示相同的值，但将来可能会改变。所以我们建议检查一下支持服务器场景的 QuicListener.IsSupported 和用于客户端的 QuicListener.IsSupported。
QuicListener
QuicListener 属于接受客户端的传入连接的服务器端类。该侦听设备是通过静态方法 QuicListener.ListenAsync 构造和启动的。该方法接受 QuicListenerOptions 类的一个实例，其中包含启动侦听设备和接受传入连接所需的所有设置。之后，侦听设备着手通过 AcceptConnectionAsync 分发连接。此方法返回的连接始终是完全连接的，这意味着 TLS 交互已经完成，连接可以使用了。最后，要关闭侦听设备并释放所有资源，必须调用 DisposeAsync 方法。
更多关于这个类设计的细节可以在QuicListener API Proposal (dotnet/runtime#67560) 中找到。
QuicConnection
是用于服务器端和客户端 QUIC 连接的类。服务器端连接由侦听设备内部创建，并通过 QuicListener.AcceptConnectionAsync 分发连接。客户端连接必须被打开并连接到服务器。静态方法 QuicConnection 和侦听设备一起，建立并实例连接。它接受 QuicClientConnectionOptions 的实例，这是一个类似于 QuicServerConnectionOptions 的类。初次之前，此链接的工作方式与客户端和服务器之间没有区别。它可以打开向外和向内的流。它还提供与连接信息有关的属性，如 LocalEndPoint、RemoteEndPoint 或 RemoteCertificate。
当连接的工作完成后，需要关闭和处置侦听设备。QUIC 协议要求使用应用层代码立即关闭侦听设备，参见 RFC 9000 Section 10.2。为此，可以调用带有应用层代码的 CloseAsync ，如果没有，DisposeAsync 将使用 QuicConnectionOptions.DefaultCloseErrorCode 中提供的代码。无论是哪种方式，都必须在连接工作结束时调用 DisposeAsync，涌起完全释放所有相关资源。
更多关于这个类设计的细节可以在QuicConnection API Proposal (dotnet/runtime#68902) 中找到。
QuicStream
QuicStream 是 QUIC 协议中用于发送和接收数据的实际类型。它起源于普通的流 Stream。可以和普通的流一样使用，但它也提供了一些特定于 QUIC 协议的特性。首先，QUIC 流可以是单向的，也可以是双向的，参见 RFC 9000 Section 2.1。双向流能够在两端发送和接收数据，而单向流只能从发起端输入数据，从接受端读取。每端都可以限制每种类型的并发流的数量，参见QuicConnectionOptions.MaxInboundBidirectionalStreams 与 QuicConnectionOptions.MaxInboundUnidirectionalStreams。
架构师必看：架构设计的四大思维支柱
笔者在 InfoQ 前文《关于架构演进发展的探讨》和《架构演进的第四个趋势：行业级标准化》中，提出了笔者对架构发展趋势的一些浅见，也介绍了企业级业务架构方法论的来龙去脉，本文拟基于上述文章提炼一下企业软件（大家常说的 B 端软件）架构设计中的四大思维支柱供大家参考。
支柱一：整体思维
一、从敏捷说起
敏捷诞生正是为了解决传统软件工程普遍被认为存在的“低效”问题，诸如周期长、不能快速响应需求、成果长期不可见而易导致失败等。
因此，敏捷往往给人“一言不合就开干”的雷厉风行的印象，而很多时候，敏捷在实操上也确实由于对“速度”和“形式”的片面追求忽视了对整体的合理设计，这样的敏捷并不是真正的敏捷，而是“着急”。
敏捷开发的几位殿堂级大师对设计的重要性有着非常深刻的认知。Martin Fowler 认为敏捷注重的是演进式设计，而不是轻视设计。
Vernon 也批评一些敏捷开发实践是用“任务板挪卡”代替了设计；Sutherland 在“OODA”循环中也强调掌握全景信息而非只从自身视角看问题的重要性，每次 Scrum 结束提出 MVP，都要重走一遍循环。
因为 MVP 就是为了获得更多、更全的反馈信息，有了这些信息才能快速决策，快速决策绝非快拍脑袋，是因为有模式加速了对信息的处理速度，这才是敏捷的原动力，也是要总结方法论的原因，“全景信息 + 思维模式 = 快速决策”。
“OODA”循环如图 1 所示：
图 1 “OODA”循环（来自互联网）
敏捷开发由于其“高效”的特点，在支持快速试错的同时，也支持快速犯错，这是一体两面的，不能只看到其由于快速提供交付物所具有的成果可见能力。
缺少整体把控，敏捷也容易堆叠“技术债务”。所以，敏捷开发也需要有整体思维做指导而不是只关注“速度”。
如果敏捷也需要整体思维，那本就因此被“诟病”的传统软件工程方法和系统分析方法也就更应该“且行且珍惜”了，众所周知，Zachman 模型、TOGAF 模型和 DODAF 模型都很强调全景信息。
二、切勿因小失大
所有局部问题的解决都离不开对整体的分析，分析的范围不同，得出的结论也会不同。举个简单的例子，如果我们为功能开发任务排定优先级。
那么，10 个任务之间进行排序和 20 个任务之间进行排序，很有可能得出排序结论是有很大差异的，分析范围会决定分析结论。
随着输入的增加，各类因素在总体上的权重就会有变化，原本认为重要的事情也可能因此不再重要了，最近大家又常提起一句话：“时代的一粒灰落在个人头上就是一座山”，其实也有这个意味。
面向局部的分析和面向整体的分析是有很大差别的，而现在的企业管理越来越注重提升整体性。
因此，B 端软件的架构设计、需求解读都应当有一个全局观，分析范围不同，解决方案也可能不同。
过于关注局部，将视野局限在小范围内，很可能会造成“因小失大”。
近年某大型电商曾在自己的支付平台上引进社交功能，但却被用于不法用途，结果导致功能下线。
该电商实力不凡，在系统设计方面也可谓独步青云，但是出现这样大的“失误”，很可能是分析问题时，没能更广泛地观察已有案例和功能实际价值对整体的贡献，低估了相关影响。
尽管上述说法未免“事后诸葛亮”，但我们不是一直希望避免出现此类问题吗？那回首原因，没做更全面的分析，就不能仅是一种“说辞”了。
三、工具何其难
基于整体分析的架构设计是一件极其耗费心力的工作，我们不能总是依靠架构师这台“碳基计算机”，总给架构师压上千斤重担而不提供支持。
架构师不是魔术师，我们也经常忘记了，“架构”是整个企业的架构而不是架构师的“架构”。
工欲善其事必先利其器。工具不仅仅是软件类工具，方法论、流程管理工具、已有的模型资产、架构管理软件都属于工具的范畴，而所有这些资产中，其实最重要的两样是方法论和模型资产。
大家可能会觉得架构管理软件更重要、更直接，但是架构管理软件是根据架构设计方法论和架构设计实践做出来的，所以方法论和模型资产是更重要的基础性工具。
而以目前架构设计的“混乱”现状而言，没有通用的架构管理工具也是必然的，因为公认能普适的架构理论和行业级标准化的模型资产都没有，也就没有合适的、可以真正直达“痛处”架构管理工具。
如果能做出这样的工具，那么，一定可以开辟一个世界级的市场。
除了工具的支持，来自企业的整体支持也很重要，不过这就属于资源层面而不仅仅是工具了。
面向整体的设计，应当有整体的参与，企业的各个部分都应当参与到整体设计中，而整体设计也应当向整个企业传导。
走不出架构师的架构设计，没有持久的维持能力；走不出 IT 部门的架构设计，不会凝聚起整个企业；走不出企业的架构设计，就无法真正落地企业战略。
支柱二：洞察能力
一、深入理解业务
洞察能力是个老话题，不过架构领域本也没多少新鲜事，任何架构方法都需要深入实践才能逐渐掌握要领，架构领域没有快餐，不大可能“一夜顿悟”，也不要急着“PK”，更多的是需要反复去啃的“硬骨头”。
做软件设计，大家常说要对业务进行深入分析，要抓住需求本质，要有合适的抽象力度，这些说的其实都是洞察能力。
洞察需要的是深入理解，而不仅仅是对需求的字面理解或者浅层的沟通。架构领域一直不乏有对哲学方法论的应用。
比如本体论，笔者近期阅读维特根斯坦的《逻辑哲学论》时也发现，尽管难以深入理解大师的思想精髓。
但是计算机领域对面向对象编程的研究与这本一次世界大战期间写就的哲学著作如出一辙。
加强洞察能力，一般都会认为是要提升思维穿透能力，这当然是必须的，但是从企业层面而言，也有相对容易操作的方式，就是加强深层次沟通。
这首先需要企业逐步改变业务人员的和技术人员的比例，使技术人员能够走到业务人员中间来，加强二者的融合。
所谓深层次沟通并不是两个人要碰撞出哲学火花，如果两个人之间只能具有一个聊聊需求的时间，就急着做产品上线了，那双方之间的了解深度必然是有限的。
技术人员如果能够轮班走到业务人员中间提供实地支持，深入理解工作环境，实际感受业务压力，理解的深度自然会增加。
我们不需要指望技术人员变成哲学家来增加洞察力，只需要给予他们更多的观察机会和思考时间。这并非“强人所难”，至少，国外的大银行，如摩根大通、高盛、Capital One 等，已经不乏这样的操作了。
可能很多人会觉得这对中小企业不公平，不可操作，毕竟他们资源有限，但是，这也取决于你是否相信“未来的企业都是科技企业”。
至少笔者相信，因为软件将是未来最主要的生产方式。也许今天很多企业不用急着进行这个操作。
但是，这不代表可以忽视这个问题，而越大的企业应该越早动手，因为企业越大转型越慢、周期越长、沟通模式越复杂，企业的全貌也越难以掌握。
二、努力推进标准化
如果软件行业整体都具备了深入的洞察能力的话，那标准化就应当是件自然的事情，农业和工业的发展都是这个历程。
农业的耕种方法、选种和培育、肥料的制作，即便在今天看来极为简陋的原始生产阶段，为了提高农业种植的成功率和产量，也是在进行着不懈的“标准化”努力。
农书早已有之，即便在著名的“焚书坑儒”中，也获准可以保留，可见古人对农业技术的重视，更不用说在现代工业条件支持下的大规模农业生产。
与之相比，软件行业真有那么特殊吗？真的不会有标准化生产这个历程吗？
反思软件行业目前的情况，也许只能说，洞察力依然不够，至少没有真正理解标准化对行业的意义。
否则，一个已经发展了 70 多年、精英辈出的行业，不会在标准化资产、标准化生产方面如此“尴尬”。
我们书写了那么多的技术标准，却依然无法提供一套能够有效复用的行业级软件资产，当然，这种复用不是指搬过来就用，而是至少不用从头做起。
开源提供了很好的支持未来大规模软件生产的模式参考，而需要的是增加对标准化的管理的思考，这也许是未来开源的发展方向。
没有标准化能力，软件行业可能无法撑起未来对软件生产的大规模需求。标准化是行业成熟的表现，也是软件行业对自身、对其他行业都具备深刻洞察力的体现，更是设计师在设计时应为之努力的方向。
支柱三：演进思维
一、唯快不破？
“快鱼吃慢鱼”几乎成了当今社会的集体“焦虑”, 企业由于竞争的压力，对“立竿见影”的追求近乎“执着”。
笔者也是个二次元的爱好者，每每想到这个问题，自然会浮现出一部漫画作品——《浪客剑心》，主人公绯村剑心的独门绝技就是“拔刀”，一回合解决对手，拔刀的瞬间就致对手与死地。
相信很多企业在搞软件建设时也寄望于此，希望采用某个架构、做成某个系统后，可以实现超级应变能力。
然而漫画作品中的主人公是在经历了地狱般的生死训练之后才具备如此能力，带着一身的伤病，成了一台需要精心保养否则很难“善终”的机器，用个通俗点儿的解释就是职业寿命比较短。
所以，“快”都是有代价、有基础的，“快”是系统性训练的结果，不是哪个部门的“快”在支撑整个企业的“快”；“快”是整个企业持续演进出来的，而不是被外部因素突然赋予的。
大家都不是漫威电影里的“超级英雄”，不是天赋异禀，也不是被蜘蛛咬一口就可以拯救世界。
不注重基础的“快”，只能是“眼见他起高楼，眼见他楼塌了”。在业务领域里，我们不乏见到业务人员被逼急了而出现的业绩造假、财务造假，而忽视软件工程的底线要求，把技术人员催的太紧，也可能出现技术“造假”。
也许笔者的说法不够准确，但是英国 TSB 银行的案例也许可以当成一个侧写吧。业绩造假、财务造假对企业管理者而言还是可以搞清楚的问题，但是技术方面出的问题，相信大部分管理者可能搞不清楚。
有兴趣的读者可以看看对计算机 BUG 的分类，像薛定谔类型、海森堡类型、分形类型等，这是连技术人员自己都搞不懂的 BUG 形态。
技术目标的实现很难一蹴而就，也许不少传统企业的管理者会问如今互联网企业不是很具备“快”的样子吗？
与传统企业相比，他们是挺快，这是因为他们具有更好的技术管理能力和开发环境，有基础设施支持人员能力的发挥，但是，不容忽视的是之前热过的“996.ICU”这个话题。
敏捷创始人可是说过，敏捷应该是高效和不用加班的。这种透支技术人员身体，把软件行业搞得像“血汗工厂”的做法，不应该用对“理想”的追求一笔带过。
传统方法只要用的纯熟、坚持对方法论的完善和演进，合适的条件下，一样可以获得“快”的效果。
比如二神山的建设就是在瀑布模型和甘特图的指导下实现“中国速度”的，感兴趣的读者可以找找二神山的工程师们公开分享的资料，看看他们对传统方法的运用。
回到正题，架构设计及其实现应该注重的是演进思维，不可能“毕其功于一役”，再着急也无法忽视客观规律。
如同搞战略设计，如果给设计人员的只有泡一碗方便面的时间，那交付的也只能是一碗战略方便面。
二、演进方向
架构设计要具备演进思维，演进思维除了意味着大目标要分段实现外，也意味着对目标该有一个整体认知，这个认知对企业软件而言，就是要统一到企业的愿景和战略上。
本文笔者延续自己在《企业级业务架构设计：方法论与实践》一书中的观点，将愿景定位于 20-30 年的长期方向，而将战略定位于 3 年左右的“短期”方向。
技术变化比较快，战略周期长了不利于调整，但是太短也很难有明显实施效果，尤其是对大型企业而言。
从长期愿景的角度看，数字化转型是必然的，当代的人碰巧处于时代切换的转型阵痛期，作为经历“痛苦”的人，任何企业和个人都无法回避这个问题。
笔者将其列为长期方向，是因为笔者所认为的数字化与目前更为贴近信息化的各类主张不同。
数字化不是一两个系统或者某个架构就可以快速解决的问题，而是整个社会的数字化，企业的数字化是社会数字化中的一环，并且，不可能仅靠自身的数字化完成。
以数字化转型为架构设计思维演进的长期方向，在每个战略周期内，密切跟踪技术的发展，适时引入可能带来业务模式变化的技术，实现新技术与业务的融合，这种架构驾驭能力才是未来企业竞争的关键。
笔者对数字化转型的详细论述包含在即将面世的新书《银行数字化转型》中，本文不再过多着墨于此。
支柱四：开放思维
一、有中心而无权威
这个说法略有“不当”，但笔者暂时没有想到更形象的表述。实际工作中，架构师在项目中是具有“权威”性的，这样比较有利于项目的总体管理，大的项目可能会有很多架构师，因为架构师的分工也是很细的，因此，从效率上来讲，也需要设立个“首架”。
“中心”会提高执行效率，但是，架构师必须具有开放性，保持谦虚，架构师是“中心”，但不要总把“权威”看得太重，架构是企业整体资产。
说的不客气点儿，企业搞架构也正是为了能够摆脱对特定架构师的“单点依赖”，使架构工作能够保持“业务连续性”。
架构设计中要保持这种谦逊性，这样才能让更好的设计思路进入设计师的视野，进入设计方案。“海纳百川，有容乃大”。
所谓的技术权威，最好是自然形成的，而非来自于职权的任命；技术权威是用来“向我开炮”的，如果用来维护，很可能会产生适得其反的结果。
技术权威最终代表的是问题能被更好地解决，而不是“唯马首是瞻”。
架构设计非常需要注重整体，尽可能考虑全景信息，这往往也意味者过于依赖“权威”架构师其实是有风险的，“智者千虑必有一失”，负担太重也会造成核心架构师“过载”。
从这个角度讲，架构师团队的开放协作，或者架构师与项目团队的开放协作是非常重要的，整体思维和开放思维之间相辅相成。
二、开放式架构设计
关于开放银行的讨论去年和今年特别多，笔者也曾发布过相关文章，在笔者看来，与其称之为开放银行不如称其为开放式架构含义会更明确。
企业之间在生态建设的“大旗”下，连接越来越紧密，而且从商业层面的连接逐渐下沉为技术层面的连接，API、SDK 等对接方式让信息化程度较高的企业之间联系更为密切。
随着企业架构理论和企业实践能力的提升，企业内部一体化程度会逐渐加强，并转化为体现生态分工的跨企业系统协作。
这要求架构设计遵循开放的设计方向，以企业之间更好地对接为目标，实现跨企业的流程整合，这样组成的“竞合”关系更稳定、更具竞争力。
面向开放式协作的架构设计，要求企业有更好的、可读性强、可公开的内部架构，这样才能有更好的协作前提。
而今天这种充满个性的架构设计风格，要逐渐向更加标准化、更容易沟通的方向发展。
PPT 不是架构师的发力点，对架构的过度宣传也许反而不利于架构的健康发展，架构风格的过度自由也许会带来沟通上的不自由。
尽管今天架构师们面对的企业环境、技术环境越来越复杂，但是，简单依然是设计应该持续追求的目标。
本文总结的四大思维支柱相信各位读者并不陌生，笔者只是将个人的一些理解融合进去。
如果用“T”型人才或者“T”型思维类比的话，整体思维相当于“T”字横头的“一”，洞察能力相当于“∣”，演进思维相当于小“T”逐步积累成大“T”，而开放思维相当于多个“T”的连接，包括企业层面、架构层面和架构师层面的开放与连接。
架构说到底就是结构和关系，架构的四大思维支柱，谈的也就是处理好结构和关系的思考原则。
结语
文章终归是一家之言，目的是抛砖引玉，希望有更多的人一起关注在当前这个大家都认定的“技术最好的时代”，我们应该如何培育“架构”这朵 IT 领域之花。
最后附上付总的大作，真的值得一看
以上是关于必看！.NET 7 在网络领域的四大更新的主要内容，如果未能解决你的问题，请参考以下文章