扫一扫
分享文章到微信
扫一扫
关注官方公众号
至顶头条
我们在本文中讨论 Web 服务时，期望在各种情况下都可以享用 Web 服务。一个主要的情况是从中间层环境（如 ASP.NET Web 页面）访问 Web 服务。为 MapPoint .NET Web 服务的用户提供支持的人员经常收到这样的问题，即用户在使用其 Web 服务时，对 MapPoint .NET 的调用可能需要相当长的时间。这本身并不是什么问题，但某些其他因素可以使之成为比表面上要严重得多的大问题。
HTTP 双连接限制
HTTP 规范表明，一个 HTTP 客户端与任一服务器最多可以同时建立两个 TCP 连接。这可以防止单个浏览器在浏览某个页面（例如，具有 120 个嵌入的缩略图）时，由于连接请求过多而使服务器负载过重。此时，浏览器将仅创建 2 个连接，然后通过这两个管道开始发送 120 个 HTTP 请求，而不是创建 120 个 TCP 连接并通过每个连接来发送 HTTP 请求。对于中间层，此方法的问题在于，中间层可能会有 50 个同时请求连接的用户。如果不得不为每个用户进行一次 MapPoint .NET Web 服务调用，将会有 48 个用户等待两个管道中的一个空闲下来。
线程池限制
ASP.NET 处理传入的请求的方式是通过一个称为进程线程池的一组线程为其提供服务。正常情况下，请求传入后，池中某个空闲的线程将为其提供服务。这里的问题在于，进程线程池不会创建无数个线程来处理大量的请求。具有最大线程数限制是一件好事，因为如果我们无限地创建线程，计算机上的全部资源将只能用来管理这些线程了。通过限制所能创建的线程数，我们可以把线程管理的系统开销保持在一个可控的水平。如果某个请求传入时线程池中的所有线程都被占用，则该请求将排队等候，在忙线程完成任务后，空闲出来的线程才能处理新请求。此方法实际上比切换到某个新线程更有效，因为不需要在请求之间进行线程切换。但存在的问题是，如果线程的使用效率不高（尤其是在非常忙的 Web 服务器上），则等候的请求队列会变得很大。
考虑一下从 ASP.NET 页面进行 Web 服务调用的情况。如果进行同步调用，则正在运行的线程将被阻塞，直到 Web 服务调用完成为止。在调用期间，线程无法进行任何其他活动。它无法处理其他请求，只能等待。如果某个单处理器计算机上具有默认的工作线程数 20，则只需 20 个同时进行的请求即可用完全部线程，以后的请求必须排队等候。
该问题不仅限于 Web 服务
不仅调用 Web 服务的用户会遇到从 Web 页面进行调用时的拥堵且耗时较长的问题。进行任意数量的较长的调用都会遇到同样的问题，例如：SQL Server? 请求、长文件的读取或写入、各种 Web 请求或访问某个并发资源（其中锁定会造成严重的延迟）。实际上，有许多使用 Web 服务的情况，其服务调用比较迅速，并不是什么问题。但您或许会理解，如果您想通过代理服务器调用 MapPoint .NET Web 服务，所使用的连接具有一定的延迟，同时相应的服务可能又要花费一些时间来处理请求，则您可能在各处位置都看到延迟的情况，并且如果站点很忙，便可能出现问题。
改善问题
该问题的某些方面可以通过对环境进行某些配置设置来改善。我们看一下可用于改善该问题的某些配置设置。
maxconnections
连接到 Web 资源的默认双连接限制可以通过一个名为 connectionManagement 的配置元素来控制。connectionManagement 设置允许您添加要让其采用非默认连接限制的站点的名称。可以将以下内容添加到典型的 Web.config 文件中，将您连接的所有服务器的连接限制默认值增加到 40。
|
＜configuration＞ ＜system.web＞ |
| maxWorkerThreads 和 minFreeThreads |
如果收到 HTTP 503 错误（“服务暂时过载”），则表明线程池中的线程已全部占用，并且请求队列也已超出最大值（appRequestQueueLimit 的默认设置为 100）。对于 IIS 5.0 安装，可以简单地增加线程池的大小。而对于 IIS 6.0 安装（与 IIS 5.0 不兼容），这些设置将无效。
maxWorkerThreads 和 maxIoThreads 分别控制工作线程数以及处理新提交的 ASP.NET 请求的线程数。这些设置需要在您的 Machine.config 中进行配置，它们将影响您计算机上运行的所有 Web 应用程序。maxWorkerThreads 是 Machine.config 中的 processModel 元素的一部分，并且您在查看后会发现，该设置的默认值为每个处理器 20 个线程。
minFreeThreads 设置可以在 Machine.config 中进行配置，或者在您的应用程序的 Web.config 文件中的 httpRuntime 元素下进行配置。该设置的作用是，当空闲的线程数低于所设置的限制时，将禁止使用线程池中的线程来处理传入的 HTTP 请求。如果您需要某个进程线程池线程完成挂起的请求，这会很有用。如果所有的线程都被用来处理传入的 HTTP 请求，并且这些请求在等待另一个线程完成其处理，那么就会进入死锁状态。例如，如果您正在从 ASP.NET 应用程序进行对某个 Web 服务的异步 Web 服务调用，并且在等待回调函数完成该请求，就会出现这种情况。因为回调必须在进程线程池中的空闲线程上进行。如果查看一下您的 Machine.config，将会注意到 minFreeThreads 设置的默认值为 8，如果工作线程池的限制为 20，则该默认值还可以满足需要，但是，如果线程池的大小增加到 100，该默认值就太小了。
应当注意的是，如果您的 ASP.NET 应用程序对本地计算机进行 Web 服务调用，则线程池限制的问题将被激化。例如，我为此专栏创建的测试应用程序调用与 ASPX 页面同处一台计算机上的 Web 服务。因而，对于阻塞的调用，一个线程被同时用于 ASPX 页面和 ASMX Web 服务请求。这有效地使 Web 服务器处理的同时请求数增加了一倍。在同时进行两个 Web 服务请求（使用异步 Web 服务调用）的情况下，我们最终使同时进行的请求数增加了两倍。为避免在回调本地计算机时出现此类问题，您应当考虑您的应用程序的体系结构，使其简单地直接从 ASPX 代码来执行 Web 方法中的代码。
Windows XP 限制
我们必须要注意，如果您在一个 Windows? XP 计算机上进行某项测试，则所面临的另一个限制是 XP Web 服务器对所允许的同时连接数的人为限制。因为 Windows XP 不是服务器平台，其同时连接数被限制为 10。这对于开发环境中的测试通常没问题，但是如果试图进行任何复杂的测试，该限制问题就会比较严重。本地计算机的连接不受此限制影响。
真正的解决方案：异步请求处理
调整配置设置是一种改善问题的方法，而在实际设计 Web 应用程序时通过某种方式彻底解决问题则是另一回事。等待阻塞的调用完成的线程永远也不会有更好的调整余地，因此，解决的办法是完全避免阻塞问题。异步处理请求就是一个适当的解决方案。这表现在两个方面：进行异步 Web 服务调用，以及在 ASP.NET Web 应用程序中异步处理请求。
异步 Web 服务调用
在以前的专栏中，我写了有关异步调用 Web 服务的问题。能够使线程不用等待 Web 服务调用完成是创建释放线程以便处理更多请求的异步页面处理模型的关键部分。此外，异步调用 Web 服务也比较简单。 请考虑以下 ASPX 页面的 Visual Basic.NET 代码：
| ' 错用同步 Web 服务调用所造成的性能极差的 ' 页面！ Public Class SyncPage Inherits System.Web.UI.Page Protected WithEvents Label1 As System.Web.UI.WebControls.Label Protected WithEvents Label2 As System.Web.UI.WebControls.Label Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load '调用 Web 服务 Dim proxy As New localhost.Service1 Label1.Text = proxy.Method1(500) Label2.Text = proxy.Method1(200) End Sub End Class |
此代码非常易懂。页面加载时将创建一个 Web 服务代理实例，然后用该实例两次调用一个名为 Method1 的 Web 方法。Method1 只返回包含传递给该方法的输入参数的字符串。为了向该系统添加一定程度的延迟，Method1 在返回字符串之前还休眠了 3 秒钟。从调用返回到 Method1 的字符串被放在 ASPX 页面上的两个标签的文本中。该页面提供的性能极差，并且像一块海绵一样从进程线程池中吸取线程。由于在 Method1 Web 方法中有 3 秒钟的延迟，对该页面的一个调用至少要 6 秒钟才能完成。
以下代码片段显示了一个类似 Web 页面的代码，只不过现在进行的是异步 Web 服务调用。
| Public Class AsyncPage Inherits System.Web.UI.Page Protected WithEvents Label1 As System.Web.UI.WebControls.Label Protected WithEvents Label2 As System.Web.UI.WebControls.Label Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load '调用 Web 服务 Dim proxy As New localhost.Service1 Dim res As IAsyncResult = proxy.BeginMethod1(500, Nothing, Nothing) Dim res2 As IAsyncResult = proxy.BeginMethod1(200, Nothing, Nothing) Label1.Text = proxy.EndMethod1(res) Label2.Text = proxy.EndMethod1(res2) End Sub End Class |
同样，该页面将创建一个 Web 服务代理，然后两次调用 Method1 Web 方法。不同的是，现在调用的是 BeginMethod1，而不是直接调用 Method1。BeginMethod1 调用将立即返回，这样我们就可以开始第二次调用该方法。与第一个示例中等待第一个 Web 服务调用完成不同，现在我们可以同时开始这两个调用。对 EndMethod1 的调用只是在特定的调用完成前会造成阻塞。值得注意的是，当我们从 ASPX 页面返回后，响应将发送给客户端。因此，在获得所需的数据之前，我们无法从 Page_Load 方法返回。这就是我们要阻塞 Web 服务调用直至其完成的原因。好的方面是两个调用可以同时执行，因此先前 6 秒钟的延迟现在将降到 3 秒钟左右。这虽然好一些，但仍然创建了阻塞的线程。我们真正需要的是在完成 Web 服务调用的同时，能够释放线程以便其处理 HTTP 请求。问题在于，ASPX 页面的处理模型没有一个异步执行模式。不过，ASP.NET 确实提供了一个解决此问题的方法。
异步 PreRequestHandler 执行
ASP.NET 支持称为 HttpHandlers 的类。HttpHandlers 是实现 IHttpHandler 接口的类，用于为带有特定扩展名的文件的 HTTP 请求提供服务。例如，如果查看一下 Machine.config 文件，您将注意到，有许多 HttpHandlers 服务于带有扩展名（如 .asmx、.aspx、.ashx 甚至 .config）的文件的请求。对于带有特定扩展名的文件的请求，ASP.NET 将查看其配置信息，然后调用与其相关联的 HttpHandler 为该请求提供服务。
ASP.NET 还支持写事件处理程序，在处理 Http 请求过程中的各个时候都可以发生这类事件。其中一个事件是 PreRequestHandlerExecute 事件，它恰好发生在某个特定请求的 HttpHandler 被调用之前。还有一个对 PreRequestHandlerExecute 通知的异步支持，可以注册这些通知以使用 HttpApplication 类的 AddOnPreRequestHandlerExecuteAsync 方法。HttpApplication 类源自基于 Global.asax 文件创建的事件处理程序。我们将使用异步 PreRequestHandler 选项为 Web 服务调用提供异步执行模式。
在调用 AddOnPreRequestHandlerExecuteAsync 之前要做的第一件事是创建一个 BeginEventHandler 和一个 EndEventHandler 函数。请求传入后，将调用 BeginEventHandler 函数。我们将在此时开始异步 Web 服务调用。BeginEventHandler 必须返回一个 IAsyncResult 接口。如果您正在进行一个 Web 服务调用，则可以只返回由 Web 服务 begin 函数返回的 IAsyncResult 接口（在我们的示例中，将由 BeginMethod1 方法返回一个 IAsyncResult 接口）。在我创建的示例中，我想执行与前面的 Web 页面示例（其中揭示了同步和异步 Web 服务调用）相同的操作。这就意味着我必须创建自己的 IAsyncResult 接口。我的 BeginEventHandler 代码如下所示：
| Public Function BeginPreRequestHandlerExecute( ByVal sender As Object, _ ByVal e As EventArgs, _ ByVal cb As AsyncCallback, _ ByVal extraData As Object) As IAsyncResult If Request.Url.AbsolutePath _ = "/WebApp/PreRequestHandlerPage.aspx" Then Dim proxy As MyProxy = New MyProxy proxy.Res = New MyAsyncResult proxy.Res.result1 = proxy.BeginMethod1( _ 500, _ New AsyncCallback(AddressOf MyCallback), _ proxy) proxy.Res.result2 = proxy.BeginMethod1( _ 300, _ New AsyncCallback(AddressOf MyCallback), _ proxy) proxy.Res.Callback = cb proxy.Res.State = extraData proxy.Res.Proxy = proxy Return proxy.Res End If Return New MyAsyncResult End Function |
关于此代码还有许多有趣的事情值得注意。首先，针对此虚拟目录处理的每个 HTTP 请求都将调用此代码。因此，我做的第一件事就是检查请求的实际路径，查看它是否是我要为其提供服务的页面的路径。我的函数使用了一些有趣的输入参数来调用。cb 参数是 ASP.NET 传递给我的回调函数。ASP.NET 希望在我的异步工作完成后，可以调用由它提供给我的回调函数。它们就是通过这种方式知道何时调用我的 EndEventHandler。同样，如果我只进行一个 Web 服务调用，则只需将回调传递给 BeginMethod1 调用，然后 Web 服务调用将负责调用函数。但在本例中，我进行了两个单独的调用。因此，我创建了一个传递给两个 BeginMethod1 调用的中间回调函数，并且在回调代码中检查两个调用是否都已完成。如果没完成，我将返回；如果已完成，我将调用原始的回调。另一个有趣的参数是 extraData 参数，它在 ASP.NET 调用我时为 ASP.NET 保存了状态。我在调用由 cb 参数指定的回调函数时必须返回该状态信息，因此，我将其存储在所创建的 IAsyncResult 类中。我的回调代码如下所示：
| Public Sub MyCallback(ByVal ar As IAsyncResult) Dim proxy As MyProxy = ar.AsyncState If proxy.Res.IsCompleted Then proxy.Res.Callback.Invoke(proxy.Res) End If End Sub |
还应当提到的一点是，我创建的实现 IAsyncResult 的类（称为 MyAsyncResult）将在查询 IsCompleted 属性时检查两个挂起 Web 服务调用的完成情况。
在 EndEventHandler 中，我只是从 Web 服务调用获取结果，然后将其存储在当前的请求上下文中。该上下文与要传递给 HttpHandler 的上下文相同。在本例中，它是 .aspx 请求的处理程序，这样它便可以用于我的标准代码。我的 EndEventHandler 代码如下所示：
| Public Sub EndPreRequestHandlerExecute(ByVal ar As IAsyncResult) If Request.Url.AbsolutePath _ = "/WebApp/PreRequestHandlerPage.aspx" Then Dim res As MyAsyncResult = ar Dim proxy As MyProxy = res.Proxy Dim retString As String retString = proxy.EndMethod1(proxy.Res.result1) Context.Items.Add("WebServiceResult1", retString) retString = proxy.EndMethod1(proxy.Res.result2) Context.Items.Add("WebServiceResult2", retString) End If End Sub |
由于已经接收了 .aspx 页面的数据，因此实际的页面处理也就非常简单了。
| Public Class PreRequestHandlerPage Inherits System.Web.UI.Page Protected WithEvents Label1 As System.Web.UI.WebControls.Label Protected WithEvents Label2 As System.Web.UI.WebControls.Label Private Sub Page_Load(ByVal sender As System.Object, _ ByVal e As System.EventArgs) Handles MyBase.Load Label1.Text = Context.Items("WebServiceResult1") Label2.Text = Context.Items("WebServiceResult2") End Sub End Class 这不仅仅是理论 -- 它确实起作用！ 如果不考虑我没有阻塞了所有线程，至少也使得浪费的资源更少了，因而这还是有意义的。但实际的结果确实会有所不同吗？答案是肯定的“是”！我把此专栏中介绍的三种测试情况放在了一起：从 Web 页面代码进行 2 个阻塞的调用，从 Web 页面代码进行 2 个异步调用，以及从 PreRequestHandler 代码进行 2 个异步调用。我使用 Microsoft Application Center Test 对这三种情况进行了测试，在 60 秒钟内从 100 个虚拟客户端连续发送请求。下图显示的结果表明了在 60 秒钟内完成的请求数。
图 1：100 个同时进行请求的客户端在 60 秒钟内完成的请求 异步 PreRequestHandler 方法处理的请求数大约是排在第二位的方法处理的请求数的 8 倍。因此，该方法使您可以处理更多请求，但是对于单个请求，实际要多长时间才能完成呢？下图显示了这三种方法的平均响应时间。
使用 PreRequestHandler 方法的平均请求响应时间仅为 3.2 秒。假设每个 Web 服务调用的内置延迟为 3 秒钟，则该方法是一种非常有效的解决办法。 我必须指出，这些并非科学的数字是在我的并非科学的办公室中运行的并非科学的计算机上获得的。当然，如果将空闲的线程释放出来，让它们做一些实际的工作确实会改善性能，因而这也很有意义。希望这些结果能够表明性能的改善其实是非常显著的。 PreRequestHandler 方法是很必要的，因为 .aspx 请求的处理程序中没有内置异步请求处理机制。但并非所有 ASP.NET HTTP 处理程序都是这样。PreRequestHandler 方法适用于所有 ASP.NET 请求类型，但使用将异步支持置于 .asmx 处理程序内的编程方式要比使用 PreRequestHandler 编程方式更容易一些。 小结 无论何时遇到任何类型的进程耗时较长的性能问题，异步执行模型都是一个很好的方法。在从 .aspx 页面调用 Web 服务的情况下，我们认为可以将异步 Web 服务调用与 ASP.NET 提供的异步执行模式结合起来。这解决了在处理 .aspx 请求的过程中缺乏异步支持的问题。使用此异步方法可以消除性能问题以及线程池资源的消耗问题。 |
濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴ｆ閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊箣濠垫劖缍楅梺閫炲苯澧柛濠傛贡缁骞掗弬鍝勪壕闁挎繂绨肩花浠嬫煕閺冩挾鐣辨い顏勫暣婵″爼宕卞Δ鈧ḿ鎴︽⒑缁嬫鍎愰柟鐟版喘瀵鈽夐姀鈥充簻闂備礁鐏濋鍛閹绢喗鈷戠紒顖涙礃閺夊綊鏌涚€ｎ偅灏い顏勫暣婵″爼宕卞Δ鈧ḿ鎴︽⒑缁嬫鍎愰柟绋垮⒔濡叉劙骞橀幇浣告倯闂佸憡绮岄崯鎶藉触椤愨懡鏃堟偐闂堟稐绮堕梺鍝ュ櫏閸嬪鎮橀幒妤佺厽闁绘ê寮剁粚鍧楁倶韫囨梻鎳呯紒顕嗙秮閹瑩鎮滃Ο閿嬪闁荤喐绮庢晶妤冩暜閹烘挾顩插ù鐓庣摠閻撴洟鏌熼幆褜鍤熸繛鍙夋尦閺岀喖顢欓挊澶婂Б闁绘挶鍊栭妵鍕疀閹炬潙娅濋梺褰掓敱濡炶棄顫忔繝姘＜婵ê宕·鈧梻浣告啞椤ㄥ棗煤閻旈鏆﹀┑鍌溓瑰敮闂侀潧锛忛崟顓炲及婵犵數濮烽弫鍛婃叏閹绢喗鏅濋柕鍫濇礌閸嬫挸顫濋悡搴＄睄閻庤娲╃紞鈧紒鐘崇洴瀵噣宕掑⿰鍛潓婵犵數濮烽弫鍛婃叏閹绢喖纾圭紓浣股戝▍鐘崇箾閹存瑥鐏柣鎾存礋閹鏁愰崘銊ヮ瀳婵犵鈧尙鐭欓柡灞炬礋瀹曟儼顦叉い蹇ｅ幘閳ь剚顔栭崰鏇犲垝濞嗘劒绻嗘慨婵嗙焾濡插綊姊洪柅鐐茶嫰婢ь垶鎮介銈囩瘈鐎殿喖顭烽幃銏ゅ礂閻撳海妾┑鐘灱濞夋盯鏁冮妷銉㈡灁濠电姵纰嶉埛鎴︽煕濠靛棗顏柣蹇涗憾閺屾盯鎮╁畷鍥р拰濡ょ姷鍋涢崯顐︺偑娴兼潙閱囨繝闈涚墕楠炴劙姊绘担鍛靛綊寮甸鍌滅煓闁规儳绠嶆禍褰掓倵閿濆骸鏋熼柣鎾跺枛楠炴牕菐椤掆偓閳ь兙鍊曞玻鍧楀箛椤撶姷顔曢梺鍛婄懃椤ャ垽顢旈崼鐔蜂患濠电娀娼ч悧蹇涙儗濞嗘挻鍋ｉ柟顓熷笒婵¤姤绻涢崼銉х暫婵﹥妞藉畷婊堝箵閹哄秶鍑规繝鐢靛仜瀵爼鎮ч悩璇茬畺闁炽儲鏋煎Σ鍫ユ煏韫囥儳纾块柛姗€浜堕弻锝堢疀閺囩偘绮舵繝鈷€鍌滅煓闁诡垰鐬奸埀顒婄秵閸嬪棛绮绘ィ鍐╃厱妞ゆ劑鍊曢弸鎴︽煕婵犲啫濮堥柟渚垮妽缁绘繈宕熼鐐殿偧闂備胶鎳撻崲鏌ュ箠閹邦喖鍨濋柣銏㈩暯閸嬫捇鏁愭惔婵堝嚬闂佷紮绲奸崡鍐差潖缂佹ɑ濯撮悷娆忓娴犫晠姊洪崨濠冪叆妞ゆ垵顦悾鐑芥晸閻樿尙顦ㄩ梺鑲┾拡閸撴艾鈻撴ィ鍐┾拺闂傚牊绋撶粻鐐烘煕婵犲啯绀嬬€规洘锕㈤崺鈧い鎺嗗亾妞ゎ亜鍟存俊鍫曞幢濡も偓椤洭姊虹粙鍧楊€楃€规洦鍓熼幆鍐敆閸曨兘鎷婚梺绋挎湰閻熝囧礉瀹ュ鍊电紒妤佺☉閹虫劙鎯屽▎鎾寸厵閻庣數枪琚ラ梺绋款儐閹告悂锝炲┑瀣亗閹艰揪绱曢惈鍕煟鎼淬値娼愭繛鍙夊灴瀹曪繝宕橀懠顒佹闂佸憡顨堥崐锝夋偄閸忓皷鎷归梺褰掑亰閸犳艾鈻旈崸妤佲拻闁稿本鐟х粣鏃€绻涙担鍐叉处閸嬪鏌涢埄鍐槈缂佺姷濞€楠炴牕菐椤掆偓閻忣亪鏌涘▎蹇曠闁靛洤瀚伴獮鎺楀幢濡炴儳顥氶梻鍌欑閻ゅ洭锝炴径鎰瀭闁秆勵殔閺勩儵鏌曟径鍡樻珔妤犵偑鍨烘穱濠囨倷閹绘巻鎸冮梺鍛婂灱椤鎹㈠┑瀣仺闂傚牊鍒€閻愮儤鐓曢柕濠忛檮閵囨繈鏌℃担鍓插剶闁哄睙鍥ㄥ殥闁靛牆鎳嶅▽顏呯箾閿濆懏鎼愰柨鏇ㄤ簼娣囧﹪宕奸弴鐐茬獩濡炪倖鏌ㄩ崥瀣敂閿熺姵鈷掑ù锝呮嚈瑜版帩鏁勯柛娑欐綑绾惧綊鏌涢敂璇插箺鐎规洖寮剁换娑㈠箣濞嗗繒浠煎Δ鐘靛亼閸ㄧ儤绌辨繝鍥舵晬婵犲灚鍔曞▓顓犵磼閻愵剚绶茬紒澶婄秺瀵鏁愰崱妯哄妳闂侀潧楠忕徊浠嬎夊┑鍡╂富闁靛牆绻愰々顒勬煛娴ｇ瓔鍤欐い鏇悼閹风姴顔忛鍏煎€梻浣稿閸嬫帡宕戦崨鎼晛闁搞儺鍓氶埛鎺懨归敐鍛暈闁哥喓鍋ら弻鐔煎箹娴ｈ櫣鏆悗瑙勬礈婢ф骞嗛弮鍫氣偓锕傚箣閻愬瓨鐝ㄩ梻鍌欑劍鐎笛呮崲閸岀倛鍥ㄧ鐎ｎ亝鐎梺绯曞墲閵囨粓鍩€椤掍礁绗掓い顐ｇ箞椤㈡绻濋崒姘兼浆闂傚倷鐒﹀鍧楀储娴犲鈧啴宕卞▎鎰簥濠电偞鍨崹鍦不婵犳碍鐓涘璺侯儏閻忊晠鏌涢弬鎯у祮婵﹨娅ｇ划娆忊枎閹冨闂備礁婀遍幊鎾趁洪鐑嗗殨濠电姵纰嶉弲鏌ユ煕濞戝彉绨兼い顐㈢Т閳规垿鎮欓崣澶樻！闂佸憡姊瑰ú婊勭珶閺囥垹绠柤鎭掑劗閹锋椽姊洪崨濠勭畵閻庢凹鍘奸敃銏ゅ箥椤斿墽锛滈柣搴秵閸嬪嫰鎮橀幘顔界厱闁冲搫鍟禒杈殽閻愬樊鍎旈柡浣稿暣閸┾偓妞ゆ巻鍋撴い鏂跨箰閳规垿宕堕妷銈囩泿闂備礁鎼ú銊╁磻閻愬搫闂繛宸簼閻撳啴鎮归崶顏嶅殝闁告梻鍠撶槐鎺撴綇閵婏箑纾抽悗瑙勬礃鐢帡鍩㈡惔銊ョ婵犻潧妫悗鏉戔攽閿涘嫬浜奸柛濠冨灴瀹曟繂鐣濋崟顐ょ枃濠殿喗銇涢崑鎾搭殽閻愬弶顥滈柣锝嗙箞瀹曠喖顢曢妶蹇曞簥闂傚倷鑳剁划顖炲礉濞嗗繄缂氱憸蹇曞垝婵犲洦鏅濋柛灞剧〒閸樼敻姊虹粙璺ㄧ闁稿鍔欏鍐差潨閳ь剟寮诲☉銏犳閻犳亽鍔庨崝顖炴⒑鐠団€虫灓闁稿鍊曢悾鐤亹閹烘繃鏅濋梺缁樓规禍顒勬儎鎼淬劍鈷掑ù锝呮啞鐠愶繝鏌涙惔娑樷偓婵嗙暦瑜版帗鍋ㄩ柛鎾冲级閺呮粓姊洪崘鍙夋儓闁瑰啿绻樺畷鎰板垂椤愶絽寮垮┑顔筋殔濡鏅剁紒妯圭箚闁圭粯甯炵粔娲煛鐏炵偓绀嬬€规洘鍎奸ˇ鍙夈亜韫囷絽骞橀柍褜鍓氶鏍窗閺囩姴鍨濇繛鍡樺姃缁诲棙鎱ㄥ┑鍡欑劸婵℃彃銈稿娲閳哄啰銈烽梺绋块绾绢厼危閹版澘绠婚悗娑櫭鎾剁磽娴ｅ湱鈽夋い鎴濇噹閳绘捇顢橀悙鈺傛杸闂佸疇妫勫Λ妤佺濠靛牏纾奸悹鍥皺婢ф洘銇勯弴顏嗙ɑ缂佺粯绻傞～婵嬵敇閻愭壆鐩庣紓鍌欒兌閸嬫挻鍒婇懞銉ｄ粓闁归棿绀侀悿楣冩煥濠靛棭妲归柛瀣у墲缁绘繃绻濋崒姘闁轰礁鐗撳铏规嫚閳ヨ櫕鐏嶉梺鎸庢磸閸ㄤ粙鐛繝鍥ㄥ亹婵炶尙绮弲銏ゆ⒑缁嬫寧婀扮紒顕嗙悼濡叉劙寮婚妷锔规嫼闂佸憡绻傜€氬嘲危閹间焦鐓熸俊銈傚亾閻庢碍婢橀悾宄扳攽閸ャ劌鍔呴梺鎸庣箓濞诧絿绮径鎰拺缂備焦锚婵鏌涙惔娑樷偓婵嬪箖閳ユ枼妲堥柕蹇娾偓鏂ュ亾閸洘鐓熼柟閭﹀灡绾墽鎮鑸碘拺闁告縿鍎辨牎闂佹寧娲忛崹钘夘嚕婵犳艾鐒洪柛鎰ㄦ櫅椤庢捇姊洪懡銈呮瀾婵犮垺锕㈤敐鐐哄箳濡や礁鈧敻鎮峰▎蹇擃仾缂佲偓閸儲鐓曢柣妯虹－婢х敻鏌曢崱鏇狀槮妞ゎ偅绮撻崺鈧い鎺戝缁犳牠鏌嶉崫鍕櫤闁诡垳鍋為妵鍕箛閳轰讲鍋撳┑瀣濠电姵纰嶉埛鎺楁煕鐏炴崘澹橀柍褜鍓欓崲鏌ユ箒闂佹悶鍎滈崨顔筋啎闂備礁澹婇悡鍫ュ磻閸涙潙鐭楅煫鍥ㄧ⊕閻撴瑩鏌熼娑欑凡鐞氭岸姊洪幎鑺ユ暠婵﹤顭烽崺鈧い鎺嗗亾缂佺姴绉瑰畷鏇㈡焼瀹撱儱娲、娑㈡倷閹绘帞鈧參姊虹粙璺ㄧ伇闁稿鍋ら幃锟犲閳ヨ尙绠氬銈嗙墬缁矂鎯冮幋鐘电＜閺夊牄鍔岄崫娲煛鐏炶濡奸柍瑙勫灴瀹曢亶鍩￠崒鍌﹀缁辨挻鎷呴幓鎺嶅闂佽鍑界紞鍡涘磻娴ｅ湱顩叉繝濠傜墛閻撴稓鈧箍鍎遍崯顐ｄ繆閸ф鐓冮柦妯侯樈濡插湱绱掔紒妯兼创鐎规洖銈搁幃銏ゆ惞閸︻厼甯ㄥ┑鐘愁問閸犳牠鏁冮妸銉㈡瀺闁挎繂鎳夊Σ鍫ユ煟閵忊懚鐟邦啅濠靛洢浜滈柡鍌涘劤鐎氬酣鏌嶈閸撴岸宕濋弴鈶┾偓鏃堝礃椤斿槈褔骞栫划鍏夊亾閼碱剙鍤┑鐘垫暩閸嬬姷浜稿▎鎾崇獥闁哄诞鍛濠电偛妯婃禍婊堟倿閸偁浜滈柟鍝勭Ч濡惧嘲霉濠婂嫮鐭掗柡宀€鍠栧畷顐﹀礋椤掑顥ｅ┑鐐茬摠缁挾绮婚弽褜娼栨繛宸簻缁犱即骞栧ǎ顒€鐏柍瑙勭⊕缁绘繄鍠婂Ο宄颁壕闁惧浚鍋呴幃娆撴煕濡ゅ懍鎲鹃柡宀€鍠栭幃褔宕奸悢鍝勫殥缂傚倷绶￠崑鍕矓瑜版帒钃熸繛鎴欏焺閺佸啴鏌ㄥ┑鍡樺窛闁伙絿鍘ч—鍐Χ閸℃ê闉嶅┑锛勫仩濡嫰锝炶箛娑欐優闁革富鍘鹃敍婊冣攽閳藉棗鐏犻柟纰卞亰閿濈偛鐣濋崟顒€鈧灚绻涢崼婵堜虎婵炲懏锕㈤弻娑㈠箻鐎靛憡鍣梺璇茬箰閸熸潙顫忓ú顏勫窛濠电姳鑳剁换渚€姊洪崫銉バｇ€光偓缁嬭法鏆﹂柕蹇嬪€曠粻鐟懊归敐鍛辅闁归攱妞藉娲川婵犲啫闉嶉悷婊勬緲閸燁垳绮嬪鍡欘浄閻庯綆鍋嗛崢閬嶆煟鎼搭垳绉靛ù婊勭矒椤㈡棃顢橀姀锛勫幍濡炪倖姊归弸濠氭嚀閸ф鐓涘ù锝嚽归弳锝団偓瑙勬礃鐢帡鍩ユ径濠庢僵妞ゆ巻鍋撶紒鐘靛仱濮婄粯鎷呯粵瀣闂佸憡鍨归弲顐ゆ閻愬搫骞㈡繛鎴炨缚閿涙盯姊虹化鏇炲⒉閽冭鲸绻涢崨顖毿ｉ柕鍥у楠炴帡骞嬪┑鍐ㄤ壕闁煎鍊曢ˉ姘攽閸屾碍鍟為柣鎾存礋閹﹢鎮欓幓鎺嗘寖闂佸疇妫勯ˇ杈╂閹烘埈娓婚柨鏇楀亾婵炶绠撻幃鈥斥枎閹惧鍘介梺缁樻煥閹诧紕娆㈤崣澶堜簻闊浄绲藉顕€鏌″畝鈧崰鏍箖閳╁啯鍎熼柕蹇ョ悼椤㈠懘姊绘担鐑樺殌鐎殿喖鐖奸獮鎰板礃閼碱剚娈鹃梺缁樻煥閸氬藟閸喓绠鹃柟瀵稿仧閹冲嫰鏌ｅ┑鎾剁瘈婵﹤顭峰畷鎺戭潩椤戣棄浜鹃柟闂寸绾剧懓顪冪€ｎ亝鎹ｉ柣顓炴閵嗘帒顫濋敐鍛婵°倗濮烽崑鐐烘偋閻樻眹鈧線寮撮姀鐘栄囨煕鐏炲墽鐓瑙勬礀閳规垿顢欓惌顐簻閻ｇ兘顢楅崟顐㈠亶闁诲海鏁哥涵鍫曞磻閹捐埖鍠嗛柛鏇ㄥ墰椤︺儳绱撻崒姘毙㈤柨鏇ㄤ簻椤曪絾绻濆顒€鑰垮┑掳鍊曢敃銈夊箖閹达附鈷戦柛娑橈梗缁堕亶鏌涢妸褎娅曟俊鍙夊姍閺屽棗顓奸崱娆忓箺闂佺澹堥幓顏嗘閺囥垺鍋╂い鎾卞灪閻撴洟骞栧ǎ顒€濡洪柟鏌ョ畺閹稿﹤鈹戦崰銏犵秺瀹曟宕楅懖鈺冣枏缂備胶鍋撳畷妯衡枖閺囥垹鐒垫い鎺嗗亾缂佺姴绉瑰畷鏇㈡焼瀹撱儱娲︾€佃偐鈧稒锚娴滄姊洪崫鍕偍闁搞劍妞介幃鈥斥槈閵忥紕鍘遍梺闈涱檧缁蹭粙宕濆顑芥斀闁挎稑瀚敮鑸点亜椤撯€冲姷妞ぱ傜窔閺屾盯濡搁妶鍛ギ濠电姭鍋撳〒姘ｅ亾婵﹨娅ｇ槐鎺懳熼幘铏础缂侇喗妫冮、姘跺焵椤掑嫨鈧線寮崼婵嬪敹闂佺粯妫佸▍锝夊汲閵忋倖鈷掗柛灞捐壘閳ь剛鍏橀幃鐐烘晜闁款垰浜剧紒妤佺☉閹冲繐鐣烽弻銉︾厱閻忕偟铏庨崵銈嗙箾閹寸儐鐒搁柡鍐ㄧ墕瀹告繃銇勯幘璺盒㈡鐐村浮濮婄粯鎷呴崨濠冨創濠电偛鐪伴崹钘夌暦閻熸噴娲敂閸涱厺绨甸梻浣告啞閸旓附绂嶅┑瀣獥闁归偊鍘剧弧鈧繝鐢靛Т閸婄粯鏅堕弴鐘电＜闁逞屽墴瀹曞ジ鎮㈢粙鍨紟婵犵妲呴崹杈┾偓绗涘懏鍏滃Δ锝呭暞閻撱垽鏌涢幇鍏哥盎闁哄鐩弻锛勪沪閻愵剛顦ㄧ紓浣虹帛缁嬫牠藝閺屻儲鍊垫慨妯哄船閸樺鈧娲橀崹鎸庝繆閹间礁鐓涢柛灞绢殕鐎氳偐绱撻崒姘偓鐑芥倿閿曞倹鏅┑鐘愁問閸犳牕煤閿曞倸桅闁告洦鍨伴崡鎶芥煏婵炲灝鍔氱紒顐㈢Ч濮婅櫣鍖栭弴鐔告緭闂佹悶鍔忓Λ鍕敋閿濆绠绘い鏃傗拡濞煎﹪姊洪悙钘夊姕闁哄銈稿畷鎴﹀箻缂佹ê浠洪梺鍛婄☉閿曪箓宕ｉ崱妞绘斀闁绘ḿ绮☉褎淇婇锝庢疁闁糕斁鍋撳銈嗗笒閸婂綊宕甸埀顒勬⒑鐎圭媭鍤欑紒澶屾嚀閻ｇ兘宕奸弴鐐嶁晠鏌ㄥ┑鍡楊伀闁烩晛閰ｅ缁樼節鎼粹€茬盎濠电偠顕滄俊鍥╁垝濞嗘挸绠涢柡澶庢硶閻ゅ懏淇婇妶蹇曞埌闁哥噥鍨堕幃鈥斥槈閵忊€斥偓鍫曟煟閹扮増娑уù婊冨⒔缁辨帡鍩€椤掑倵鍋撻敐搴″幋闁稿鎸鹃幉鎾礋椤掑偆妲瑰┑鐐茬摠缁矂鎮ユ總绋课ュù锝呭濞笺劑鏌嶈閸撶喖鐛崘顔碱潊闁挎稑瀚板顔界節閵忥絾纭炬い锕侀哺瀵板嫰鏁撻敓锟�
现场直击｜2021世界人工智能大会
直击5G创新地带，就在2021MWC上海
5G已至 转型当时——服务提供商如何把握转型的绝佳时机
寻找自己的Flag
华为开发者大会2020（Cloud）- 科技行者
京公网安备 11010802021500号