不可或缺的APM

ZD至顶网软件频道消息： 各位朋友们好，今天我会花一点时间跟大家讨论一下APM这个议题，这个议题在一两年里在全国各地都是非常受关注的一个议题。为什么呢？因为这个跟企业有非常相关的关系。现在企业有什么？我们会发现有几个很重要的情况，很多企业现在都往数字化的模式上推进，把现有的一些传统业务转变成数字化的。但是，在这个过程中他们会碰到非常多的挑战：例如在业务层面上需求，增加的速度是非常快的，以前可能会几个月才会有新的需求，现在从月变成周，甚至每天都有一些新的需求。而且在需求增加的过程中，用户的期望越来越高，包括在功能、性能等多个维度方面，用户的要求越来越高，而且用户环境也是越来越复杂。

除此之外，以前用户只是通过单一的浏览器进行访问，但是现在很多基本的简单的访问是通过手机进行的。重要的是，手机的品牌、操作系统的版本数量都是爆炸性增长，企业如何去管理那些不在可控范围里那些用户的环境，这也是一个非常大的挑战。另外一个挑战是，如何在有限的资源条件下做更多的事情，这也是很多企业现在会遇到的问题。

因此， APM首先要进行监控，有了监控的数据，我们才可以了解现在所处的环境和状态，才能够根据环境和状态进行对应的控制。如果没有监控数据，就相当于在一个摸黑的环境，这种情况下，企业只能靠猜进行判断，那么所产生的风险就会非常高。这也是很多企业对监控特别看重的原因。

在监控过程中，一旦遇到问题，企业会问，“这个问题跟性能、响应速度等方面相关？这是运维的问题还是跟企业其他的团队相关？”这也是我们在整个监控过程中要考虑的。我们应该先上哪个团队，关注什么维度，要得到什么样的效果，这都是很重要的议题。

现在，回到刚才讲的问题，APM是不是就是指监控？答案是，APM只是监控的一小块，但是却是非常重要的一部分。以往，很多企业都会部署监控，但是这类的监控多数是针对基础设备的监控，包括服务器、网络等，这是因为企业的大部分资源都是在建架构。但是，回过头来想一想，企业部署监控是为了确保基础设备的运作是良好的，进而才能保证这些由基础设备构建的平台是运行良好的，进而保证平台上运行的应用是良好的。因此，应用是很重要的一部分，整个基础设备都是集中在提供一个平台以便运行相关的应用。

那么，应用又是做什么的呢？应用主要服务企业的用户和员工，这也是整个监控过程里面一个很重要的部分。APM包括应用的部分监控，还有用户体验，我们所做的这些事情包括整个基础设备、开发这么多应用、对这些进行监控，这一切工作的最终目的就是为了服务用户。我们能不能把用户体验呈现出来，可以看到他们的感受，也要串联到应用的质量、性能、跟基础设备的关系等，这个意义就变得很大。

还有一点也是我们比较关注的，以前关注的部分就是在整个过程里面，为什么我们关注用户的体验，也是因为必须要跟业务挂钩，跟业务没有联系其实就没有太大的意义。

所以，现在主要的APM集中的部分，包括应用监控跟用户体验的部分。刚才提过，APM会跟企业内部不同的团队都会相关。整个项目是从业务开始的，从画面左上角可以看到，当有一些新的计划出来，我们怎么去保证我推出这个新的服务时，这个服务是已经准备好了的，可以支撑不同数量的用户，并且是有顺序地推出来，不会因为一个新的推广可能导致整个网站出现宕机的情况。如果没法刷新，会直接影响到企业的品牌，只要有一点的事故出现，现在媒体都会进行很多采访，这也是业务推广中企业所担心的事情。

当然，当有这个新的服务概念出来以后，下一个会直接影响到的团队就是开发测试团队。因为你必须要把中间提供服务的整个架构，整个应用产生出来，所以在整个开发过程里面我们怎么去在最短时间把最好质量的应用推出来，怎么能把它推到这个市场上面，这也是在整个开发团队里面需要关注的，这也会跟APM相关，因为这边会拿到很多性能和质量指标，可以帮助开发测试的团队去提升应用的质量。

    现在，应用已经做好了，并且推到生产的环境中.这时候，运维团队最关心的是，怎么去满足SLA，假如出现问题怎么快速地定位问题，把故障位找出来。除此之外，运维团队还关系在问题发生之前，如何进行预警，不要等问题出来了才去处理，这可以说是整个应用生命周期里面的一个部分，也是APM的每一部分都会牵涉到的。其实还有一个部分也非常重要的，当业务推出一个新的服务,怎么知道它的服务效果怎么样，要想得到这些，我们在生产环境里除了拿到那些性能数据以外，也需要拿到一些业务关心的数据，包括有多少用户在用、应用的交易使用状况、假如出现问题这个问题是不是能很快速定位解决，这个都是整个周期里面一个很重要的环节，这也可以说是整个APM在应用生命周期每一部分都会相关的。

    我们后边会看一些例子，看一下在不同的环节里面怎么去利用APM提升效率。第一个案例是运维的例子。我们说监控是不是所有都要看，这个可能是一个理想，一般情况下不是这样，我们总会有关心的应用，应用里面有关心的一些交易。从画面上面部分我们可以看到，监控的第一部分是我们关注的最主要的一些交易，主要的应用中的相关交易。还有一点就是一些重要的指标，有哪些重要指标，这些有多少人在用，有多少用户受影响。除了这个以外，出现的问题发生了多久，有多少人受影响，这也是很重要的。这个很容易理解，假如事故刚发生，其实运维的压力不会很大，还有时间去处理，但是假如这个问题发生了半天还没解决，那么运维的压力就会很大。另外，受影响用户的数量也是企业关心的问题，受影响的用户数量越大对企业的影响也就越大。从一个广度的方式去看，运维会看到的是所有的你相关的所有应用的状态，跟里面的一些重要的交易指标。

从这个开始我们就会往里面去看，假如我发现有一些交易有问题，其实我们关心的就是下一步的细节，运维关心的是什么？有没有问题、问题出在哪一个环节。这个结果不一定需要很细，但是它必须要在一个很快速广泛的角度去看到，哪些环节出现问题，或者有机会开始出现问题，这时就往里面抓，看看中间有问题的是哪一个节点、哪一个部分，是网络的问题，还是服务器的问题，然后用最简单最快速的手段把它定位出来。

针对这个例子，一般最简单的办法是通过“红绿灯”定位到某一些交易出现问题，就从那边钻进去，画面下部分可以看到整体的交易响应时间的趋势，哪些用户受影响、有多少用户，以此判断这个问题是不是严重。

APM一个很重要部分就是可以提供很重要的指标供我们评估，假如我出现一堆问题的时候，哪一些是需要优先处理的。我们可以从前一个画面再进去看看所有的一些重要指标，表现它的可用性是什么，在这个过程里面哪一些交易是受影响的。好像是我的网站有问题，我中间层企业的应用，好像SAP，会不会它里面的交易时间很长。

除了这个以外还有一点很重要，我们讲APM不单只是监控真实用户的，其实也会搭配交易的，会从交易里面提供一些线索，系统里面是不是有问题，而且它也可以做预警。刚才我们看到SAP里面可能有一点问题，APM的好处是可以帮你去追踪个别的一些用户，只要有一些用户抱怨，我们就可以看到他当时是在做什么，也可以从他当时出现的一些状况和异常，去判断他遇到的问题是跟哪个系统的环节有关，然后我们就可以找相关的人员去帮助他处理这个问题。这是从运维的角度去看APM可以帮它做什么。

我们也可以换个角度看一看，这个案例有一点不一样，不纯粹是响应时间的问题。这是我们另外的客户，他在他的订票系统里面做整个流程的监控，看看这是每一个过程，因为一般网站订票可能会跳过不同的页面，他把每一个页面访问的用户人数、响应时间，所有的这些数据整合做一个仪表板，主要看看会不会因为一些指标影响页面的响应时间和用户整个订票的过程。这很容易理解，假如我在订票过程中有一些页面特别慢的话，我可能会离开的，这表示会影响到业务转换率。在线订票过程中，用户可能会因为一些原因，诸如受不了页面的响应时间而离开，导致企业丢失一些交易，APM就可以帮企业去做这方面的分析。

而且我可以从不同维度去看，这纯粹都是跟业务相关的，包括我订票里面的转换率，用户是从哪个地方来的，在画面里面会看到很多小小的小点，这个点有红绿黄一些圈圈，圈的大小表示什么？圈越大表示这个地方访问的用户越多，红黄绿很容易理解，就是它的用户体验，他是满意还是不满意。

    我们从这边可以判断到一些地区，访问的用户只要出现问题，是不是跟这个地区相关，有哪个地方的用户他的感受是最好还是不好的，针对这些我们可以做很多的处理。除了这个以外我们也可以做一些仪表板，好像画面的右边我会看到一堆不同的指标，包括退出情况和用户环境的指标，这样我就可以从业务的角度去看，到底系统哪里做得不好。而且重点这只是整块APM的一部分，这个数据其实还可以跟后边的技术数据串联起来，只要业务发现问题，或者用户发生一些状况，我还可以从这个业务角度开始出发去追踪是不是技术上的问题，包括这是另外一些的业务指标，也是客户那边当时做的时候也要求我们帮助他去看，整个网站的转换率和网络流量跟满意度之间的关系。

    还有就是一些其他有趣的东西，有一种页面叫“离开页”，哪些用户是最多从那个地方离开的，假如有些页面是特别多用户，是不是做得不好还是其他原因，这都是从监控的角度，从业务角度关注的一些问题。这也可以说是在APM另外一些层面。

    当然，刚才讲过，APM和测试开发也是相关的。一般来讲应用上线以前都会做压力测试，很重要的目的是保证上线的时候新应用可以支撑足够的访问量。但是，这也是一个评估的方法，压力测试能告诉你在某一个指定的压力量下，应用能通过还是不通过，另外，这个过程中新应用没有通过，原因是什么呢？一般我们的处理手法可能是去看日志，看一些不同的指标，尝试去定位这个问题，然后再找开发商帮我修改这个问题。

 但假如我手上这些日志不能提供足够的信息修改应用，尝试去猜一下问题在哪，去加多一点日志，加一点的数据，帮我们去定位这个问题。当然，另外的做法，假如他们不能确定，我当然可以重新再尝试一次，再做一次，加多一点的指标，去看看能不能定位这个问题。

当然，这种尝试会花的时间比较长，而且没有一个比较准确的方法。经过统计，这种方法解决问题，大概要跑4-5次的压力测试才可以完成，但是也要注意一点，做压力测试不是想什么时候做就能什么时候做，需要前期进行准备，所花费一定资源，时间是蛮长的，一般我们上线以前线上时间不多，这种做法效率不会很高。我们需要一些更好的方法，最好在压力测试的同时能够快速把问题定位，这也是APM能帮上忙的地方。

我们看另外一个案例，这是一个用户在压力测试的过程里边收集的数据，就是在后台放了一些代理去收集应用的执行状况，我们发现一个非常有趣的部分，在执行过程中我们看到整个交易花很多时间在同步，每一个交易大概花了7-8秒，因为我们从这边可以很细钻进去看，同步过程占用时间是卡在哪一段的代码，或者哪一个方法里。

从这边我们可以发现，同步的过程一种在等，等的是什么呢？跟数据相关的。同时我们从不同的仪表板里面也可以看到，整个压力测试的过程中存在跟很多数据库相关的错误，而且也很明显看到有一些系统的参数指标是有问题的，它的数量花光了，所以变成很多往后的交易没法连到数据库，所以产生错误，其他要等数据库连线能提供了，因此一直在等，导致了应用的整体性能下降。

其实，在定位问题的过程中我们不用做很多事情，只需要几个步骤就可以很快定位到这个问题。而且我们会发现在第一次测试时有一些交易的响应时间是非常长的，但是透过一些简单的调整，把那个连接的数量修正了以后，我们发现整个交易过程可以从十几秒下降到不到1秒钟就可以完成，这也可以说是在整个APM里面和整个测试过程里面一个非常有价值的部分，它可以告诉你整体的应用执行状况，假如有问题出在哪个地方，是代码还是配置，或者其他。

当然，我们运维环境里面或多或少还有其他不同的问题，APM最好的地方就是可以在生产环境里面去收集那些交易上的所有的细节，假如出现问题可以很快速地定位到问题在哪个地方。在下面这个例子里面，我们会看到在整体的执行过程中出现一些内存的问题，在这个部分我们其实也很快速透过画面上边的一个简单的追踪，一两个点击就可以看到问题出在哪一段代码，然后我们只要从代码里面再看，跟开发人员沟通就可以知道问题出在哪个地方。这个例子也不会很复杂，因为我们在这个案例里面，我们的开发人员发现整个开发过程里面他的代码把所有查询的数据都拿到内存，但是它没有限制数量，只要用户输入一个很宽的条件，他会把很多数据都来到那个内存里面，会导致内存的问题。一般，这种情况在整体测试时不一定很明显看到，但是我们可以提供这种信息。

接下来，是生产里面蛮有趣的一个案例，这个案例做什么呢？跟死锁有关，我不只是在一个用户里面看到，很多用户碰到同样的问题，这个死锁假如我们从画面看，它锁在日志，一般我们以前做开发的传统做法，有问题我就写日志，写的日志越清楚我就可以很快去追踪所有很多问题的细节。

但是，假如你的日志出现问题，这个是IBM里面用了一个标准的日志库，这个库里面会有什么问题呢？它是单线程的，假如我是纯粹用传统直接写日志，会发现什么问题呢？一个在写，第二个在等，等第一个写完了第二个可以继续。但是假如在问题爆发的同时，很多用户都要写日志，结果就是后边的人在等，交易就会变得特别慢。

但是，当高峰过了，当前面的所有日志完成了，你后面用户要写的日志都已经消耗了，又变回正常。但是，假如没有工具你纯粹看日志你看不出来这个问题，你知道很慢，日志不一定告诉你中间有死锁，通过APM等工具我其实可以很快速地看到问题出在哪个地方，也可以重新再想一想我应该怎样去写日志，用什么最好的一些方法去写，这不是纯粹有问题就直接写进去，尤其在生产出现问题的时候你不一定容易能找到这个问题。

一个很有趣的部分，我们大部分的用户都会使用移动设备，但是移动设备最大的问题是，企业很难就每一种设备的客户端进行逐一测试，目前市场上主流的手机品牌、版本其实蛮多的，安卓的至少超过200个不同品牌的厂商，你不可能每一台都测试，而且还有它不同的版本。这样情况下我们要怎么做呢？我怎么知道我的用户现在用什么的手机，我们很多时候就会透过在生产环节里面去收集这方面的数据。

这个案例是我们手机的用户，它是一个跑步运动距离计算的手机应用，它有什么问题呢？它大部分都很好，但是有用户投诉，它跑步距离的计算不准，还好它有用到APM的工具去追踪用户在手机上的一些行为。从收集到的数据可以会看到某一些用户会产生一些错误，最后发现一些非常有趣的问题，不是所有手机都有这个问题，是某一个品牌的手机在某一个操作系统的版本下才会出现这个问题。这样情况在平常测试过程中不容易找到，因为在测试时不可能所有组合都测试一遍，而我们在生产里面去定位可以快速地回应到用户，知道什么问题也知道怎样去处理，这也是APM可以提供的价值，在生产里面帮我去追踪一些我们平常不容易看到的问题。

除此之外，作为一个工具，最好的APM方案是要能够整合企业的整个环境，从开发、测试，再到运维。怎么将整个开发环境作一个持续的交互，这是很重要的部分。从开发工具开始，串联到测试环境、源码的管理，以及构建的自动化过程。通过APM能够整合的话，你可以把整个过程变得非常简单，你的任何代码的改动、测试过程、数据的收集，都可以实现自动化，让整个开发周期的管理过程大幅度缩短。

还有一个很重要的，我们刚才讲了一篇有蛮多历史都跟这个代码相关，其实做APM有不同的技术，没有一个单一的技术能涵盖了所有需求。刚刚我们看到一些例子，但是我们很难明确的区分，具体是用哪一种技术。现在我给大家一个概念，我们一般有几个做法，一个是从网络角度做监听，一般是透过一种旁路的方式，从交换机做定向，把所有的网络交互和通讯都收集下来，然后做一些分析。这种的好处是你可以做一个广度的追踪，你不会把整个数据中心里边的所有应用一次的做一个分析，可以看到中间所有用户的交互，会有一些性能的问题。它的好处是广，而且是可以大范围的处理，但是它的缺点就是没有办法深入的去到服务器里面的代码层面。

所以我们会搭配另外一种做法，是透过一个代理的方式，代理的方式其实也有分几种，一种是在数据中心监控应用、应用服务器、数据库。但是我们还有一个很重要部分，就是用户体验的管理。但是，用户的管理和网络、应用的处理的方法有点不一样，例如，如果说数据中心都是可控的环境，要怎么去处理，安装什么东西，都可以容易比较管理。但是，用户我们会通过另外一些办法，因为用户是不可控的，用户使用哪些终端、他是哪个地方的、他用什么方式，这些都没办法管。所以我们会通过一些自动化的手段，假如是浏览器用户的话，我们会通过页面的标签，把那些相关的脚本送到用户端里面，以用户的角度收集。这个也是一个在APM里面很重要的考虑的东西。

我再补充一个部分，刚才我们没有很明确的区分用什么手段，去做APM。其实没有一个单一的技术可以把所有用户的需求都能做到的，APM通过几个不同的技术和不同的手段去做的。包括第一个我们会看到画面里边，旁路的一个方式，透过网络的这个角度，从网络那边我们一般会从旁路，从交换机，从你的交换机里面把用户的行为交互都收集下来。分析他的封包，然后去判断用户体验、性能、使用的情况。从网络的角度进行管理的好处，是可以把整个数据中心里的所有的应用、所有交易都收集下来，进行分析，会有整体的广泛的监控。但是它的特点是，它没办法做深入的追踪，假如发现问题出在某一台服务器的话，你就需要通过另外一些手段，一般的做法就是透过画面中间代理的方式，代理的方式是会在服务器里面安装一些代理，未追踪应用底层的执行状况，收集一些性能指标，各种不同纬度的指标，去判断一些质量和性能的问题。

但这个也有一些分类的，因为假如说代理的话，一般我们的想法都在数据中心里边的代理，但是我们其实在监控过程里边，也需要关心用户的感受。在数据中心中，应用的响应时间很快，不代表在用户端也是很快的，我们也会透过一些技术从用户的角度，收集他感受和性能指标。这个部分，一般假如是BS应用的话，我们会透过一些标签从浏览器的页面，送到用户端，直接从用户端里面去收集应用性能和数据，这个都是透过归类代理的做法。

代理的做法的好处就是可以非常深入的看到用户的那些很明细的数据，当然这个数据量是蛮大的，这两个部分我们都称为被动的监控。有用户才会有数据，但是假如没有用户的时候，我怎么知道我的系统是好还是不好呢？我们就会透过另外一个手段，透过摩尔用户，有的时候我们又把它叫做主动监控，透过一些机器人，在不同的点去执行一些指定的交易。这个好处是什么？它有两个重点，第一我会看到的是一些主动的监控，假如还没有用户开始发现问题的时候，摩尔的交易可能会告诉我，你的系统开始出现问题。另外一点，因为它是固定的点，所以可以根据这些做比较，我会看整体的交易趋势，例如在一周中，某个事件的交易时间是特别有问题的，这些有没有规律。主动监控就可以做这个分析。

可以说，在整个APM里边，有不同的技术，每一种技术都有它的特长和特点，以及限制。整体来讲，能把几个配合起来，可以变成一个完整的监控，涵盖企业不同维度方面的需求。在评估APM方案的时候，我们会用什么方式？其中一个我们都会参考Gartner这个国外分析公司，它提供了一个很明确的方向，这家公司每年也会针对的APM厂商做评估的。包括我们会从几个维度去看，第一就是用户体验，这也是很重要，不单只是应用性能，也是要看用户的性能。然后就是在整个运行的过程中，把握系统的框架，整个发现，这个也要显示出来。

当我知道整个系统里边的运行状况、所有的服务器、节点之间交互的关系，还有就是可以做一些业务的分析，包括用户自定义的。除了这个以外，还有一点也是标准的，就是必须可以追踪到应用底层的状况。另外有一点很重要的，收集这么多数据，我们一般想法都是性能业务，用户那边其实也需要拿到这个数据做分析，这就要求APM能够把一些性能数据抽出来，做一些业务、用户行为那些分析。当然要评估很多的材料，我在画面里面提供有网站，也提供了一个非常完整的评估APM方案的一些文档，可以给大家作为一个参考。

做一段广告吧，我们也是一家APM的厂商，我们最新推出了一个运用监控的版本，这边有很多新的功能，加到这个新的版本。但是我不会每一个方案去讲，因为时间有限制，我集中在几个部分。一个部分，我们在最新的6.3版本，提供了一个延伸了整个追踪的端对端的范畴，从我们的数据库的监控，再往数据里边深入的看里边到底发生了什么事情。这是一个蛮有趣的部分，待会儿我们会详细讲讲。当然，在运维也好、在开发也好，是有更多的监控的一些指标，我们提供了更多维度的不同的仪表板，增加很多功能，帮用户去从不同维度做监控。

这一点我们刚刚提到，就是做分析，这个分析是什么？怎么把APM的数据分析？作为一个APM厂商，我们不是做数据分析的，但是我们能把所有用户的行为、指标，都收集下来，而且是针对每一个用户的，不是简单的统计数据。所以，我们可以利用我们的工具，把那些数据收集交到其他的分析工具，做一些后期的用户行为的分析，这个也是一个部分。当然其他的有机会我们可以再谈一下。

我们看数据库代理这边的部分，这个产品有三个功能。我可以从我的仪表板里边去打开，看到我的数据库的执行状况，除了这个以外，还有一点很重要的，我可以看到执行的每一个系统里边它的执行计划是怎么样的。在同时也可以看到，当时数据库里边执行的用户交易同时，有没有其他人也在用，假如只有一个出现问题，这个是我写的不好，但是如果其他人也影响到的话，现在我可以很明确的包括你，这个状况是怎么样的。在这边有两个画面，左边就是可以告诉我，现在我的数据库里边有哪个人在用，他占用的资源是什么。右边这个，我可以挑一些我不满意一些语句，看看它的执行计划是怎么样的，这样我就可以判断，我写的好不好，需要不需要做一些调整。

这是一大堆不同的画面，我把它拆分的比较细一点。从左上角看一看，这个是跟开发相关的，我现在可以追踪到每一个用户，它访问的过程里边，它的整个响应时间细分的部分，通过哪些指标。我们可以看到，他在寻找我们网站，连线的时间，第一个位源的时间，所有时间我都可以看到。我就可以看到，是不是我的网页，要调优的时候从哪个角度开始。还有就是，我也可以做一些的页面上数据的收集，假如我有一些重要的业务数据在页面上，其实我们现在这个版本里边，我会定义它把这个内容拿出来，放到我的仪表板，包括一些业务的数据、用户的状态，以及其他与用户相关的数据。

除了这块以外，我们的仪表板提供了更丰富的分析功能，包括它可以显示过程里边，把用户整年的数据，都可以整理显示出来。这边先是到我们背后，其实系统里边有一个类似大数据的环境，把用户的所有行为数据，做一个整合，分析以后，很快速的在画面里面呈现出来。提供了更多仪表板更细致的分析的功能，这个也是这个版本可以带给用户的。除了这个以外，刚刚我们讲了分析的部分，分析这个是蛮有趣的。现在我们作为一家APM厂商，我们有不同的那些模块，包括可以从网络收集数据，也可以从代理里面收集数据，而且我们每一个模块现在都已经做了一些产品化，就是这些数据可以透过一个标准的方式，送到其他的环境，好像这边我们在这个版本里边，提供这个叫PureLytics数据流的一个功能。可以把用户行为，包括他整个访问的过程，他每一个步骤，他做了什么，送出去，以JSON的格式送到ElasticSearch里去，这样我就可以通过ElasticSearch搭配工具kibana去分析，做一些其他的用户行为的分析。

这个是kibana仪表板这是从我们APM的方案里面，把数据突出去，这有一些用户相关的仪表板。还有一个有趣的应用，就是我们同事做了一个分析，我们的网站，通过我们的工具，对所有用户去收集点击的数据，形成hitmap，这样我们就能够知道，在整个网站页面中，哪个部分是用户点击最多的，这个也是一种用户行为分析。

这个是一个非常容易、功能强大的工具，当然讲是非常理想的，最好是真的去感受一下，它的功能能帮企业做到哪些事情。所以我们也提供了一个30天的免费试用的版本，可以在画面中的地址申请，这跟完整的版本是一模一样。除了这个以外，APM这个议题很多人很关注，也是有兴趣知道，怎么样去把APM做好，我们每年都会举办叫perform的大会，我们会邀请我们的客户分享他在使用APM方面的一些经验。今年，这个大会会在7月上旬在上海举办，只要有兴趣的话也可以在画面上这个地址报名。

今天我的内容大概是这样，谢谢大家！