谈谈华为微服务解决方案与实践

• 华为云微服务引擎的前世今生

华为从12年开始在很多创新项目里应用微服务技术，在14年随着微服务框架技术越来越成熟，工具越来越完善，公司各个产品线开始基于微服务框架做云化产品，16年的时候公司为了更好的进行能力共享，决策把散落在公司各个产品线的一些与微服务相关的工具、平台、框架和团队统一整合成华为公司级paas平台重要组成的一部分，专门负责微服务平台的交付和技术演进，统一支撑整个华为公司产品微服务化转型，在17年随着云BU的成立，公司就把这个内部微服务能力以云服务的形式放到华为云上开放出来，这样可以让业界更多的企业和开发者能更方便的使用微服务技术，少走弯路。截止当前华为无线、云核心网、消费者云等基于此微服务框架都已完成云化及商用。

• 微服务在业界的使用状况

下面这张图是著名的开源软件Nginx，在官网面向全球开发者做的一次关于微服务使用情况的调研，从这份数据可以看到，目前接近70%的开发者正在使用或试用微服务技术，其中接近30%的企业已经在生产环境中使用微服务， 也就是说微服务早已经过

了概念炒作阶段，已经是实实在在地进入到了成熟商用阶段。其实，从华为内部看，微服务解决方案目前已广泛应用于华为消费者云、无线产品线5G、企业智能EI、内部流程IT、云核大视频等等核心产品领域，是公司业务全面云化的基座。

• 为什么要用微服务

在讲为什么要用微服务前，先看看企业的原始业务诉求有哪些？随着云化和互联网技术的发展，企业的it部门从原来的成本中心转变成生产中心，如何将客户需求和软件价值更快的交付到客户手中成为企业的核心竞争力之一，以前是大鱼吃小鱼，现在是快鱼吃慢鱼；现代软件应用的领域越来越广，无论是工作，生活还是娱乐，这些应用（特别是消费类应用）有些会有明显的流量波峰波谷，例如游戏一般在工作日和白天玩的少，而在休息日和晚上玩的多，还有一些应用无法预期流量，可能大部分时间流量一直稳定，而一个意外事件的发生就会导致流量指数级增长，无论是哪一种场景，都要求应用架构能具备更好的弹性能力来保证业务的可用性；经过这么一波互联网技术洗礼之后，行业边界正变得越来越模糊，很多企业特别是传统行业都希望通过业务创新获取新的增长点，而我们都知道业务创新九死一生，那么低成本的快速试错是迫切追求的，怎么样低成本，其实从IT部门视角来看，如果能基于团队已有的技能，重用企业已有的技术资产（比如投资了很贵的技术平台软件），这就是节省成本，另外一点，不同行业不同领域都有不同技术栈，举个对程序员最能理解的例子，开发语言没有绝对的好坏，例如java，c++，python，go等都有它最适合的场景，大多企业的技术决策者都希望能用最合适的技术去匹配业务，所以在选择能支撑未来业务持续发展的基础性框架和平台产品时，对技术开放性的考量也是至关重要的。

另外，从很多客户（包括华为内部的业务团队，以及外部的合作伙伴和各种类型的企业客户），还反馈了这样一些诉求，例如：高可用性、容错性、可管理性、可替代性、可测试性、组织扩张、架构弹性。。。。。。其实从这些反馈不难看出，业界对微服务的诉求不仅仅是需要某个单点问题或一个工具套件，而更多的是希望通过微服务这种新的研发理念来改变整个研发活动的方方面面，包括技术、组织和流程的变革。

从最终的业务视角来看，我们认为微服务的价值可以简单总结为三个词，即：更快、更稳、更经济。微服务的本质是化繁为简，分而治之，从而加快企业创新。

更快，是指业务上线的速度，使用微服务能把业务上线周期从年降到月、周，甚至是随时上线；更稳，是指系统可用性，基于微服务构建的系统能把系统SLA从3个9提升到4个9、5个9，甚至永不断服；更经济，是指业务的资源成本，基于微服务更细粒度的弹性，能实现业务规模扩张与资源支出的最佳平衡。

借用赤壁之战这个耳熟能详的典故，可以更形象的理解微服务与传统单体架构的区别：如果一千多年以前曹操不把自己的百万大军用铁链连成一个像单体应用一样的整体，而是让每条船像微服务一样，能独立指挥独立作战，也许就不会被孙刘的一把火烧的这么狼狈。

• 微服务带来哪些新的挑战

任何事务都有两面性，微服务也不例外。从我们经历的这么多实践项目来看，微服务主要带来的挑战如下：

微服务本身也属于分布式技术的一种，分布式系统对编程的门槛其实是很高的，传统的单体应用因为是单进程，组件A与组件B的进程内调用只需使用编程语言的语法，一行简单的代码就能搞定，根本就不用考虑服务发现、负载均衡、限流容错等等技术，但是在微服务系统里，服务A调服务B时，首先要找到服务B在哪里，有可能服务A和B部署在同一个节点上，也有可能服务A部署在深圳，而服务B部署在北京的一个机房，所以服务的注册发现是微服务应用开发人员需要解决的第一个问题，找到服务B以后，有可能服务B是多实例部署，这时候又需要在多个服务实例中找一个最合适的实例来处理请求，那么这就涉及到第二个问题：负载均衡，后面还有服务调用失败了要考虑服务容错，还有服务限流、服务降级、分布式事务等等诸多复杂的分布式技术问题，如果我们把这些问题都留给业务开发人员，显然业务开发是快不起来的，这就是微服务化之后面临的第一个问题：如何基于微服务架构高效开发和上线。

从一个单体应用拆分成多个独立运行的微服务应用，从理论上来说，系统的故障点是增多的，用户请求的每一跳都有可能出错，特别是在资源受限的大规模流量冲击下，这又引入微服务化后的第二个问题：如何在不可预期的流量下如何保证业务的高可靠运行。

而微服务系统的运维是个更显而易见的问题，一般传统的单体应用问题定位过程是这样的：首先登录到出故障的应用节点，然后找到应用的相关日志文件，导出到本地后就可以使用各种文本工具进行日志分析和问题定位，整个过程很简单，人工就能搞定，但在微服务系统中，特别是在动辄上百个微服务和实例部署的场景下，一个业务请求很可能跨越了多个微服务多个实例多个节点，别说定位问题，就是先搞定问题定界都很难，这时候如果没有一个自动化的工具或平台来支撑，靠人力是不可能完成的任务。

最后是一个非常现实的问题，特别是在传统企业里面，都会有一些遗留的资产或运行中的业务系统，不可能把这些都推倒重来，不仅成本太高，而且业务风险也大。如何将传统架构下的遗留系统低成本的向微服务架构迁移也是微服务解决方案需要系统考虑的。

同时真正要实施好微服务，对企业的组织架构、业务流程以及人的素质模型都提出了新的要求，所以向微服务转型是一个企业系统性的变革活动。

• 华为微服务解决方案是什么

华为微服务产品包含一套微服务开发框架、一站式微服务监控与治理平台以及一系列配套的微服务开发工具，主要功能如下：

l   基于契约(Open API)的开发模式：让微服务的开发、测试、文档、协作和管控活动标准化、自动化

l   高性能REST/RPC微服务开发框架：打包了微服务注册、发现、通信和治理等基础能力，开箱即用

l   一站式微服务治理控制台：提供微服务负载均衡、限流、降级、熔断、容错、错误注入等治理能力

l   非侵入式微服务：提供Mesher服务，可实现多语言微服务解决方案，以及遗留系统零改造微服务化

l   多样化微服务安全管控能力：提供认证鉴权、黑白名单等能力保障微服务访问安全

l   灰度发布支持业务平滑升级：支持使用接口任意参数（例如用户群组、用户类别、用户所属区域等等）定义微服务灰度发布规则

l   微服务调用追踪：提供微服务实例和接口级吞吐量、时延和成功率的实时监控及调用链分析

这套微服务产品完全是从公司各条业务战线上提炼而来，自始至终贯彻易用、开放、多场景和企业级的理念进行设计和演进的：因为要服务于内部数万微服务开发者，这些开发者的能力参差不齐，如果不易用门槛不放低，使用和推广成本就会非常高；因为要服务于内部各种不同类型的业务，如运营商、企业、消费者、流程IT等，如果架构不开放就无法做到基于一套框架灵活定制按需使用；因为除了要满足新业务开发、也要满足老业务平滑迁移、还要满足和三方系统方便集成，如果不能适应多场景，不考虑平滑演进，应用范围就会非常的窄；因为公司基本上所有业务都是全球交付，在性能、可用性、安全性上不做到企业级就根本没法商用。同时基于华为聚焦微服务技术领域多年的持续投入，目前已在多个方面做到了业界或国内首创，例如：面向国内提供了首个多语言微服务框架，首个商业版Service Mesh产品，并大规模应用于生产环境；业界首个进入Apache开源社区的微服务框架ServiceComb。

另外，我们也有一个专业的微服务评估（参考下图，已在华为云上开放自助评估服务）和咨询团队，能帮助企业完成从微服务适用性评估、服务划分到落地实施（平台和工具使用支撑）等微服务化转型端到端的解决方案。

• 华为微服务框架与开源框架的区别

可能还有很多人会有这样的疑问：我之前用开源框架好好的为什么华为还要重复造个轮子？这个就要回顾华为微服务框架的发展历程了，起初华为也是拿开源框架改吧改吧就用了，但是在支撑公司内部各种业务的过程中发现了不少问题，简单罗列几点，一是语言绑定，当前开发语言层出不穷，其本身就说明业务对开发语言是有诉求的（不同的业务需要合适的语言来开发），同时特别是在云服务生态里，对不同语言开发的微服务能够方便的互通成了基本要求；二是协议支持单一，基本要么只支持RPC，要么只支持REST，而实际有的场景仍然在使用或需要传统的Web Service（例如SOAP等等）协议，有的场景为追求极致的性能都有自己深度定制的私有协议，有的场景面向不同接入方式需要同时发布多种协议的服务接口；三是性能和易用性问题，例如Spring Cloud把微服务的各种能力（列如注册发现，路由管控，能力接入等等）都拆分成了独立的部件由使用者根据实际场景来组合使用，其本身确实提供了极大的灵活性，但灵活性的背面是复杂性，对人员能力的要求较高，同时其性能（例如并发量和时延）并不乐观，在一些要求苛刻的场景显得力不从心。

总之，太多经验表明，把一堆开源软件包变成可用，再到可商用，中间有太多的坑需要填平，华为就是这样填着填着，后来发现基本变成了一个新的东西。事实上，我们在开源基础上提供了十多项关键能力的增强，这些也都是从我们经历过的一些活生生的经验教训，交了无数学费后总结而来。

• 华为微服务Service Mesh解决方案

Service Mesh是当前业界比较火的一个热点技术，华为也是国内最早把这个技术落地，推出商业版产品，并大规模应用于生产环境的云服务提供商。其实技术归技术，真正要有用还是要用它来真正解决现实问题，目前主要用来解决客户的两类问题：第一类是那种使用一些语言（如php、.net、nodejs、python等）开发微服务，但业界没有合适的微服务框架能直接使用，所以只能使用这种代理方式来解决微服务的注册发现及路由管控等问题；第二类是那种有一大堆遗留应用，一行代码不想改，又希望能使用微服务的高级治理能力，如灰度发布、限流降级等等，这时候通过这种非侵入的技术就能很方便的搞定。

另外，再补充一点关于微服务SDK与Service Mesh技术之争，目前业界有些声音认为Service Mesh是下一代微服务技术，会替代SDK模式。从当前实际的业务诉求看来，这两者在微服务功能上确实有些重合，例如在微服务的路由管理、遥测和安全这些方面的能力，两种方式都可以实现，但SDK本身还有另外一个职责，就是标准化微服务的团队交付方式，例如：标准化了微服务的打包方式（软件包定义、编译设置、依赖管理）；标准化了微服务的发布方式（服务定义、如何注册配置监控、通信协议、安全认证等等）；标准化了微服务接口的定义方式（数据模型定义、操作模型定义）；标准化了微服务公共能力的开发方式（动态配置、日志记录、监控埋点、事务协调、文件存储、数据库/缓存/消息中间件访问）。标准化的目标是为了规范化和自动化，而这两者是提高团队研发效率的基本手段。当然，一个作坊式软件开发团队，人数少，业务规模小，管理没那么复杂，随便怎么干影响也不大，但当你的研发团队增长到近百人，甚至上千规模时，标准化的开发方式是支撑团队高效工作的基本要求。

• 华为微服务流水线解决方案

微服务的交付过程跟以前其实没什么区别，都是从coding、编译、打包、测试、部署到上线这些基本的交付活动，但是微服务模式下却比以前更加需要流水线这么一个自动化的工具平台来支撑，主要是微服务的数量太多了（动辄几十上百），交付活动中的任何一个环节无法自动化就会对整个业务上线效率造成很大的影响，很容易导致业务微服务化之后不仅没快起来，反而比以前更慢，别小看这一点，我们所经历过的大部分微服务转型项目都掉过这个坑。大家都知道，提升效率的最好办法就是尽可能自动化，而能自动化的前提是先把业务或者活动进行建模并标准化，微服务流水线看上去是一套工具平台，本质上是对团队开发活动中各个环节进行了一系列标准化，从微服务编写第一行代码开始，包括微服务的开发方式，如微服务的定义、接口的定义、周边依赖集成方式等，也包括微服务的交付过程活动，如编译、打包、测试和部署模板、脚本和环境配置都进行了标准化，这样能让开发人员聚焦业务本身逻辑的开发，以及简化团队之间的协作，最终实现整体交付效率的提升。

• 华为微服务灰度发布解决方案

在互联网行业，特别是一些业务创新场景都强调要快速试错，很多面向消费者的优秀应用并不是从一开始就设计好的，而是通过不断的快速迭代、快速试错，逐步进化而来的。我们理解快速试错其实包含两种场景：其一，不得不承认无论怎么加强测试，因为各种因素（例如环境差异、场景差异、人的差异等等）是软件都会有一些bug成为漏网之鱼，如果无法避免这些bug，那我们希望当这些bug出现时尽可能影响最小化；其二，我们会很高频率的上线一些小的特性，这些特性有的来自于部分客户的需求，有的来自于行业洞察，有的来自于愿景规划，但这些新的特性是不是所有用户都喜欢的，或者还有哪些改进点，我们希望这个发布过程能管控起来，灰度发布就是一个很好的解决途径，我们可以通过对新版本的发布范围、使用对象、甚至使用场景进行细粒度控制，这样就能最大化降低发布风险。

当然，灰度发布的适用场景并不局限于此。曾经遇到过有个客户的应用场景挺有意思，他们运营着一个物业电梯管理的SaaS应用，发现每个客户对都有些不同程度的定制诉求，一开始没想太多反正定制工作量也不大，就为每个客户定制一个版本然后各自部署一套，张三就访问张三的那一套，李四就访问李四的那一套，相安无事挺好，可是后来他们发现这样搞资源太浪费了，因为这些系统其实90%以上的功能都一样，而各自部署的服务器资源利用率都很低，于是后来他们做了一件事，把面向不同客户的定制部分抽出来做成独立的微服务，然后通过配置灰度规则，让不同用户访问到各自定制版微服务上，通用功能只部署一套，这样就大大节省了资源，而且还减少了维护工作量。

• 华为微服务治理解决方案

在微服务系统上线之后，我们要尽可能的做到运维的自动驾驶，因为靠传统那种手拉肩扛的运维方式是不可能运维好复杂的微服务系统的，这里更大的挑战是对微服务运行时各种指标的监控和及时响应都提出了非常高的要求。

微服务的治理措施有很多，例如负载均衡、黑白名单、服务限流/降级/容错/熔断、故障预测/自愈等等，我们可以根据实际的应用场景选择相应的治理措施，例如：

负载均衡：这不是一个新技术，但这里重点说一下在微服务系统里负载均衡的应用方式有什么不同，传统的应用架构一般是分层的，例如从外到里有接入层、展示层、业务逻辑层、持久化层，我们一般在系统的最外层加一个F5或Nginx作为负载均衡器，来确保入口处的流量被均匀的分配到后端的处理服务上。但是在微服务系统里，由于服务粒度小了很多之后，整个架构并没有明确的层次之分，更多的像个网状结构（如下图），

每个微服务都可能多实例部署，这时候每个微服务之间的访问也需要负载均衡，如果用传统的方式在每个微服务之间加一个F5或者Nginx，这是不可能的，首先成本就受不了，所以需要从微服务框架就要支持这种能力。负载均衡的策略可以有多种，例如轮询、随机、会话粘滞（如果用户请求第一次访问了某个实例，则后续该用户的所有请求都访问这个实例）、实例负载（根据当前所有实例的负载，例如CPU使用率来判断闲或者忙，再来决策路由到合适的实例）、响应权值（根据所有实例历史处理请求的响应延时情况，来选择满足SLA的实例）等等。

容错熔断：任何微服务之间的任何一次调用都有可能会失败，但我们的系统又必须做到更好的SLA，这就要求架构师在微服务的设计之初就要考虑到各种失败场景和应对措施，当然把这种工作都交给业务开发人员来处理，门槛会非常高，好在我们已经在微服务框架里内置了一些容错能力，例如调用一个实例失败了可以尝试重试几次，也可以选择路由到另一个正常的实例，当所有实例都失败可以启用自定义的预案措施，同时对于后续的调用可以快速失败返回，以防止交通堵塞。熔断的场景就类似于我们家里用于电路上的保险丝，当发现某个微服务的负载较大时，系统会自动把到该服务的流量掐掉，直到监测到负载正常时再恢复。

限流降级：任何微服务的容量（处理的最大请求量）都不是无限的，所以要进行限流的治理，以保证微服务不被无论正常还是恶意的流量搞垮，另外一个场景，我们可以根据请求方的消费级别（例如铂金用户、黄金用户、普通用户等）来分配不同的流量限制，以实现差异化的商业服务。降级主要应用在两种场景：其一，有些时候当系统中的某些服务挂掉了，为了防止故障蔓延，可以把对故障服务的调用降级掉，以保证系统的其他功能还能用，例如不可能因为商品广告服务出故障而导致整个电商网页打不开，可以把广告服务降级，让用户至少可以打开首页浏览商品；其二，在一些资源受限的场景，可以主动降级掉系统中一些非关键服务来保证核心服务的资源诉求，例如在电商促销活动之前，可以把非关键的日志服务、评论服务或者推荐服务等等通过降级的方式先关掉，把资源调配给核心的商品列表、下单、支付等服务。

黑白名单：我们有很多企业客户为了在内部实现数据共享和能力共用，来提升公司运作效率，会把一些内部企业支撑系统通过微服务的方式发布出来，但是有些数据会比较敏感不适合在太大的范围公开，因此对处理这一类数据的微服务自然而然就有了安全管控的要求，通过黑白名单管理就可以很方便的控制微服务的访问范围。

还有很多有用的治理手段，这里就不一一列举，有效的治理措施取决于对微服务系统运行状态精确的监控，我们需要做到对微服务360度监控，例如：微服务所在集群和节点的CPU、内存、磁盘和网络等资源指标的监控，微服务本身的吞吐量、时延和错误率等应用指标的监控，以及微服务所依赖的数据库、缓存、消息、网关等中间件指标的监控，跟就医看病一样，只有对病情有足够的诊断，才能开出最合适的药方。

• 华为微服务开源进展和路标

2017年6月，在由Linux Foundation主办的LinuxCon + ContainerCon + CloudOpen（LC3）开源峰会上，华为宣布开源微服务框架ServiceComb，开源后的ServiceComb将帮助广大开发者快速开发云原生应用，共同推进构建行业云生态。

又于同年11月，开源社区 Apache 软件基金会孵化器项目管理委员会 ASF IPMC宣布华为云开源的 ServiceComb 项目全票通过进入 Apache 孵化器。这也是华为继 CarbonData 之后，第二个进入 Apache 孵化的开源项目。

进入 Apache 孵化器，也意味着 ServiceComb 社区将遵循Apache Way,社区将更加开放、中立及多样化，也欢迎更多的厂商及个人开发者参与社区。

华为开放微服务框架的逻辑也很简单：其一，这确实是一个经过内部广泛实践验证过的好东西，捐献出来希望能进一步促进行业更快的向微服务转型；其二，微服务的生态很大，华为不可能也没有能力涉猎各行各业，所以希望抛砖引玉，联合大家一起完善生态；其三，微服务框架是业务开发的基础组件，全部开源出来也可以打消很多华为客户担心被技术绑定的疑虑，华为提供的微服务相关商业产品也都是基于这套开源版本构建的。

• 华为微服务案例

从卖光盘到卖服务：一个PHP语言系统微服务化的案例

这是一家国内知名的软件开发商，他们开发了一个楼宇的物业管理系统（一个单体应用），最开始的商业模式是卖光盘，和某个小区签一个合同就过去给他们安装一套软件，基本是一锤子买卖的生意，后来他们想按SaaS模式去卖，先把这套软件部署到云上，签一个合同就为开通一个账号，这样一来就有了客户粘性，后续可以持续升级卖服务。这种商业模式的变化其实也悄悄的对软件架构带来了一些影响，例如以前一个地方部署一套，业务的流量不会很大，系统的性能是远远过剩的，但是以SaaS这种方式去面对多客户，随着业务量越来越大，单体应用的性能就会越来越吃不消，这也促使他们不得不把系统向微服务架构改造。后来他们在启动改造开发的时候，又发现当前业界还没有合适的PHP语言微服务框架，而当前他们开发人员的技术栈都是PHP的，这时候要换语言或者换人都是成本比较高的，于是他们找到了华为通过Mesher来解决微服务化的问题。

Mesher不限制语言，而且提供了完备的微服务治理能力，如服务注册发现、路由管理、灰度发布、流水线等等，这样不仅仅支撑他们完成了微服务架构转型，通过弹性解决了系统性能瓶颈问题，还额外获得了业务上线效率提升的收益。

传统企业的微服务化之路：一个大型遗留系统向微服务架构迁移的案例

这是一家地产行业的公司，他们有一个古老的CRM系统，这个系统有一部分功能是面向潜在购房者的，例如客户服务、机会服务、房源服务、代理服务等等，受一些互联网营销的影响，他们也把楼盘放在网上开盘销售，前几年房地产行业比较火爆，经常也会有秒光盘，这时候在抢房瞬间的流量压力这种场景下，他们的CRM系统就扛不住了，导致系统体验不好，影响企业品牌和形象。于是找到华为希望做微服务改造，但这个项目最大的困难是当前的CRM系统太庞大了，而且很多地方都是日积月累的不敢随意去动。后来我们针对性能做了深入分析，发现瓶颈主要是抢房这块相关的功能，于是我们把这块功能拆解出来单独做了微服务化改造，其他系统功都不动，只在边界部分做一个和新微服务交互的简单适配，这样把抽出来的业务繁忙的这些微服务做适当的弹性就解决了性能问题，而且通过这种微服务粒度按需的弹性还大大提升了资源利用率（以前必须整个CRM系统大颗粒的弹性）。

在超大规模用户和流量场景下的微服务应用案例

如果读者用的是华为手机，手机上的应用市场、浏览器、音乐、支付、负一屏、运动健康、智能家具等等背后都是运行在这套微服务框架之上，目前华为消费者云超过4亿用户。举这个例子主要是想说明华为的这套微服务解决方案也是经历超大规模流量这种应用场景洗礼过的，所以无论多大业务量规模，在性能、安全和可靠性上没有任何问题。

一个由基于Spring Cloud自建微服务系统最终向华为云CSE迁移的案例

这是一家物联网领域的创业公司，主要为城市、公园、园区等提供专业的智慧路灯服务，并在此基础上结合监控、传感器等其他物联网终端，提供各种创新应用场景，如寻人寻物、犯罪线索提供等，原系统基于Spring Cloud微服务构建，开源软件的特点就是功能很多很灵活，但是真正要吃透用好是门槛挺高的，创业公司本来投入资源就有限，化大量的人力物力来维护这些基础的技术组件是不值得的，他们也是在用了好久之后实在是维护不下去，才找到华为帮他们提供商业级微服务解决方案。因为CSE本身是兼容Spring Cloud的，所以这次的切换很快，一周完成框架切换并上线，将原来全职投入的框架维护人员全部释放出来投入到业务开发中。

一所高校所经历的微服务转型之路

这是一家坐落在上海的985高校，其实学校也有很多系统有类似互联网这种有明显波峰波谷的应用场景，例如在每学期的开学阶段，有新生报到、课程安排、在线选课等等事务，在学期末阶段又会有集中性的考试、答辩、结业等等事务，处理这些事务背后的IT系统其实也就在这几个阶段会忙一点，其它时间基本闲置，很多学校的痛点就是资源准备少了不够用，撑不住那几个时间点的流量，准备多了又浪费，于是希望把传统的这些教务系统微服务化，能充分的利用弹性和公有云的能力，来降低成本的同时还能解决业务波峰波谷的性能瓶颈问题。