• 关于

    交换算法未响应

    的搜索结果

回答

负载均衡是由多台服务器以对称的方式组成一个服务器集合,每台服务器都具有等价的地位,都可以单独对外提供服务而无须其他服务器的辅助。通过某种负载分担技术,将外部发送来的请求均匀分配到对称结构中的某一台服务器上,而接收到请求的服务器独立地回应客户的请求。均衡负载能够平均分配客户请求到服务器列阵,籍此提供快速获取重要数据,解决大量并发访问服务问题. 软件负载   基于特定服务器软件的负载均衡   ---- 这种技术是利用网络协议的重定向功能来实现负载均衡的,例如在Http协议中支持定位指令,接收到这个指令的浏览器将自动重定向到该指令指明的另一个URL上。由于和执行服务请求相比,发送定位指令对Web服务器的负载要小得多,因此可以根据这个功能来设计一种负载均衡的服务器。一旦Web服务器认为自己的负载较大,它就不再直接发送回浏览器请求的网页,而是送回一个定位指令,让浏览器去服务器集群中的其他服务器上获得所需要的网页。在这种方式下,服务器本身必须支持这种功能,然而具体实现起来却有很多困难,例如一台服务器如何能保证它重定向过的服务器是比较空闲的,并且不会再次发送定位指令?定位指令和浏览器都没有这方面的支持能力,这样很容易在浏览器上形成一种死循环。因此这种方式实际应用当中并不多见,使用这种方式实现的服务器集群软件也较少。   DNS负载   基于DNS的负载均衡   ---- DNS负载均衡技术是最早的负载均衡解决方案,它是通过DNS服务中的随机名字解析来实现的,在DNS服务器中,可以为多个不同的地址配置同一个名字,而最终查询这个名字的客户机将在解析这个名字时得到其中的一个地址。因此,对于同一个名字,不同的客户机会得到不同的地址,它们也就访问不同地址上的Web服务器,从而达到负载均衡的目的。   ---- 这种技术的优点是,实现简单、实施容易、成本低、适用于大多数TCP/IP应用;但是,其缺点也非常明显,首先这种方案不是真正意义上的负载均衡,DNS服务器将Http请求平均地分配到后台的Web服务器上,而不考虑每个Web服务器当前的负载情况;如果后台的Web服务器的配置和处理能力不同,最慢的Web服务器将成为系统的瓶颈,处理能力强的服务器不能充分发挥作用;其次未考虑容错,如果后台的某台Web服务器出现故障,DNS服务器仍然会把DNS请求分配到这台故障服务器上,导致不能响应客户端。最后一点是致命的,有可能造成相当一部分客户不能享受Web服务,并且由于DNS缓存的原因,所造成的后果要持续相当长一段时间(一般DNS的刷新周期约为24小时)。所以在国外最新的建设中心Web站点方案中,已经很少采用这种方案了。 .基于四层交换技术的负载均衡   ---- 这种技术是在第四层交换机上设置Web服务的虚拟IP地址,这个虚拟IP地址是DNS服务器中解析到的Web服务器的IP地址,对客户端是可见的。当客户访问此Web应用时,客户端的Http请求会先被第四层交换机接收到,它将基于第四层交换技术实时检测后台Web服务器的负载,根据设定的算法进行快速交换。常见的算法有轮询、加权、最少连接、随机和响应时间等。   七层负载   基于七层交换技术的负载均衡   ---- 基于第七层交换的负载均衡技术主要用于实现Web应用的负载平衡和服务质量保证。它与第四层交换机比较起来有许多优势:第七层交换机不仅能检查TCP/IP数据包的TCP和UDP端口号,从而转发给后台的某台服务器来处理,而且能从会话层以上来分析Http请求的URL,根据URL的不同将不同的Http请求交给不同的服务器来处理(可以具体到某一类文件,直至某一个文件),甚至同一个URL请求可以让多个服务器来响应以分担负载(当客户访问某一个URL,发起Http请求时,它实际上要与服务器建立多个会话连接,得到多个对象,例如.txt/.gif/.jpg文档,当这些对象都下载到本地后,才组成一个完整的页面)。  
不语奈何 2020-01-09 18:27:49 0 浏览量 回答数 0

回答

134题 其实就是水平扩容了,Zookeeper在这方面不太好。两种方式:全部重启:关闭所有Zookeeper服务,修改配置之后启动。不影响之前客户端的会话。逐个重启:这是比较常用的方式。 133题 集群最低3(2N+1)台,保证奇数,主要是为了选举算法。一个由 3 台机器构成的 ZooKeeper 集群,能够在挂掉 1 台机器后依然正常工作,而对于一个由 5 台服务器构成的 ZooKeeper 集群,能够对 2 台机器挂掉的情况进行容灾。注意,如果是一个由6台服务器构成的 ZooKeeper 集群,同样只能够挂掉 2 台机器,因为如果挂掉 3 台,剩下的机器就无法实现过半了。 132题 基于“过半”设计原则,ZooKeeper 在运行期间,集群中至少有过半的机器保存了最新的数据。因此,只要集群中超过半数的机器还能够正常工作,整个集群就能够对外提供服务。 131题 不是。官方声明:一个Watch事件是一个一次性的触发器,当被设置了Watch的数据发生了改变的时候,则服务器将这个改变发送给设置了Watch的客户端,以便通知它们。为什么不是永久的,举个例子,如果服务端变动频繁,而监听的客户端很多情况下,每次变动都要通知到所有的客户端,这太消耗性能了。一般是客户端执行getData(“/节点A”,true),如果节点A发生了变更或删除,客户端会得到它的watch事件,但是在之后节点A又发生了变更,而客户端又没有设置watch事件,就不再给客户端发送。在实际应用中,很多情况下,我们的客户端不需要知道服务端的每一次变动,我只要最新的数据即可。 130题 数据发布/订阅,负载均衡,命名服务,分布式协调/通知,集群管理,Master 选举,分布式锁,分布式队列 129题 客户端 SendThread 线程接收事件通知, 交由 EventThread 线程回调 Watcher。客户端的 Watcher 机制同样是一次性的, 一旦被触发后, 该 Watcher 就失效了。 128题 1、服务端接收 Watcher 并存储; 2、Watcher 触发; 2.1 封装 WatchedEvent; 2.2 查询 Watcher; 2.3 没找到;说明没有客户端在该数据节点上注册过 Watcher; 2.4 找到;提取并从 WatchTable 和 Watch2Paths 中删除对应 Watcher; 3、调用 process 方法来触发 Watcher。 127题 1.调用 getData()/getChildren()/exist()三个 API,传入 Watcher 对象 2.标记请求 request,封装 Watcher 到 WatchRegistration 3.封装成 Packet 对象,发服务端发送 request 4.收到服务端响应后,将 Watcher 注册到 ZKWatcherManager 中进行管理 5.请求返回,完成注册。 126题 Zookeeper 允许客户端向服务端的某个 Znode 注册一个 Watcher 监听,当服务端的一些指定事件触发了这个 Watcher,服务端会向指定客户端发送一个事件通知来实现分布式的通知功能,然后客户端根据 Watcher 通知状态和事件类型做出业务上的改变。工作机制:(1)客户端注册 watcher(2)服务端处理 watcher(3)客户端回调 watcher 125题 服务器具有四种状态,分别是 LOOKING、FOLLOWING、LEADING、OBSERVING。 LOOKING:寻 找 Leader 状态。当服务器处于该状态时,它会认为当前集群中没有 Leader,因此需要进入 Leader 选举状态。 FOLLOWING:跟随者状态。表明当前服务器角色是 Follower。 LEADING:领导者状态。表明当前服务器角色是 Leader。 OBSERVING:观察者状态。表明当前服务器角色是 Observer。 124题 Zookeeper 有三种部署模式:单机部署:一台集群上运行;集群部署:多台集群运行;伪集群部署:一台集群启动多个 Zookeeper 实例运行。 123题 Paxos算法是分布式选举算法,Zookeeper使用的 ZAB协议(Zookeeper原子广播),二者有相同的地方,比如都有一个Leader,用来协调N个Follower的运行;Leader要等待超半数的Follower做出正确反馈之后才进行提案;二者都有一个值来代表Leader的周期。不同的地方在于:ZAB用来构建高可用的分布式数据主备系统(Zookeeper),Paxos是用来构建分布式一致性状态机系统。Paxos算法、ZAB协议要想讲清楚可不是一时半会的事儿,自1990年莱斯利·兰伯特提出Paxos算法以来,因为晦涩难懂并没有受到重视。后续几年,兰伯特通过好几篇论文对其进行更进一步地解释,也直到06年谷歌发表了三篇论文,选择Paxos作为chubby cell的一致性算法,Paxos才真正流行起来。对于普通开发者来说,尤其是学习使用Zookeeper的开发者明确一点就好:分布式Zookeeper选举Leader服务器的算法与Paxos有很深的关系。 122题 ZAB协议是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议(paxos算法的一种实现)。ZAB协议包括两种基本的模式:崩溃恢复和消息广播。当整个zookeeper集群刚刚启动或者Leader服务器宕机、重启或者网络故障导致不存在过半的服务器与Leader服务器保持正常通信时,所有进程(服务器)进入崩溃恢复模式,首先选举产生新的Leader服务器,然后集群中Follower服务器开始与新的Leader服务器进行数据同步,当集群中超过半数机器与该Leader服务器完成数据同步之后,退出恢复模式进入消息广播模式,Leader服务器开始接收客户端的事务请求生成事物提案来进行事务请求处理。 121题 Zookeeper本身也是集群,推荐配置不少于3个服务器。Zookeeper自身也要保证当一个节点宕机时,其他节点会继续提供服务。如果是一个Follower宕机,还有2台服务器提供访问,因为Zookeeper上的数据是有多个副本的,数据并不会丢失;如果是一个Leader宕机,Zookeeper会选举出新的Leader。ZK集群的机制是只要超过半数的节点正常,集群就能正常提供服务。只有在ZK节点挂得太多,只剩一半或不到一半节点能工作,集群才失效。所以,3个节点的cluster可以挂掉1个节点(leader可以得到2票>1.5),2个节点的cluster就不能挂掉任何1个节点了(leader可以得到1票<=1)。 120题 选完Leader以后,zk就进入状态同步过程。1、Leader等待server连接;2、Follower连接leader,将最大的zxid发送给leader;3、Leader根据follower的zxid确定同步点;4、完成同步后通知follower 已经成为uptodate状态;5、Follower收到uptodate消息后,又可以重新接受client的请求进行服务了。 119题 在zookeeper集群中也是一样,每个节点都会投票,如果某个节点获得超过半数以上的节点的投票,则该节点就是leader节点了。zookeeper中有三种选举算法,分别是LeaderElection,FastLeaderElection,AuthLeaderElection, FastLeaderElection此算法和LeaderElection不同的是它不会像后者那样在每轮投票中要搜集到所有结果后才统计投票结果,而是不断的统计结果,一旦没有新的影响leader结果的notification出现就返回投票结果。这样的效率更高。 118题 zk的负载均衡是可以调控,nginx只是能调权重,其他需要可控的都需要自己写插件;但是nginx的吞吐量比zk大很多,应该说按业务选择用哪种方式。 117题 Zookeeper 的核心是原子广播,这个机制保证了各个Server之间的同步。实现这个机制的协议叫做Zab协议。Zab协议有两种模式,它们分别是恢复模式(选主)和广播模式(同步)。当服务启动或者在领导者崩溃后,Zab就进入了恢复模式,当领导者被选举出来,且大多数Server完成了和 leader的状态同步以后,恢复模式就结束了。状态同步保证了leader和Server具有相同的系统状态。 116题 有临时节点和永久节点,分再细一点有临时有序/无序节点,有永久有序/无序节点。当创建临时节点的程序结束后,临时节点会自动消失,临时节点上的数据也会一起消失。 115题 在分布式环境中,有些业务逻辑只需要集群中的某一台机器进行执行,其他的机器可以共享这个结果,这样可以大大减少重复计算,提高性能,这就是主节点存在的意义。 114题 ZooKeeper 实现分布式事务,类似于两阶段提交,总共分为以下 4 步:客户端先给 ZooKeeper 节点发送写请求;ZooKeeper 节点将写请求转发给 Leader 节点,Leader 广播给集群要求投票,等待确认;Leader 收到确认,统计投票,票数过半则提交事务;事务提交成功后,ZooKeeper 节点告知客户端。 113题 ZooKeeper 实现分布式锁的步骤如下:客户端连接 ZooKeeper,并在 /lock 下创建临时的且有序的子节点,第一个客户端对应的子节点为 /lock/lock-10000000001,第二个为 /lock/lock-10000000002,以此类推。客户端获取 /lock 下的子节点列表,判断自己创建的子节点是否为当前子节点列表中序号最小的子节点,如果是则认为获得锁,否则监听刚好在自己之前一位的子节点删除消息,获得子节点变更通知后重复此步骤直至获得锁;执行业务代码;完成业务流程后,删除对应的子节点释放锁。 112题 ZooKeeper 特性如下:顺序一致性(Sequential Consistency):来自相同客户端提交的事务,ZooKeeper 将严格按照其提交顺序依次执行;原子性(Atomicity):于 ZooKeeper 集群中提交事务,事务将“全部完成”或“全部未完成”,不存在“部分完成”;单一系统镜像(Single System Image):客户端连接到 ZooKeeper 集群的任意节点,其获得的数据视图都是相同的;可靠性(Reliability):事务一旦完成,其产生的状态变化将永久保留,直到其他事务进行覆盖;实时性(Timeliness):事务一旦完成,客户端将于限定的时间段内,获得最新的数据。 111题 ZooKeeper 通常有三种搭建模式:单机模式:zoo.cfg 中只配置一个 server.id 就是单机模式了,此模式一般用在测试环境,如果当前主机宕机,那么所有依赖于当前 ZooKeeper 服务工作的其他服务器都不能进行正常工作;伪分布式模式:在一台机器启动不同端口的 ZooKeeper,配置到 zoo.cfg 中,和单机模式相同,此模式一般用在测试环境;分布式模式:多台机器各自配置 zoo.cfg 文件,将各自互相加入服务器列表,上面搭建的集群就是这种完全分布式。 110题 ZooKeeper 主要提供以下功能:分布式服务注册与订阅:在分布式环境中,为了保证高可用性,通常同一个应用或同一个服务的提供方都会部署多份,达到对等服务。而消费者就须要在这些对等的服务器中选择一个来执行相关的业务逻辑,比较典型的服务注册与订阅,如 Dubbo。分布式配置中心:发布与订阅模型,即所谓的配置中心,顾名思义就是发布者将数据发布到 ZooKeeper 节点上,供订阅者获取数据,实现配置信息的集中式管理和动态更新。命名服务:在分布式系统中,通过命名服务客户端应用能够根据指定名字来获取资源、服务地址和提供者等信息。分布式锁:这个主要得益于 ZooKeeper 为我们保证了数据的强一致性。 109题 Dubbo是 SOA 时代的产物,它的关注点主要在于服务的调用,流量分发、流量监控和熔断。而 Spring Cloud诞生于微服务架构时代,考虑的是微服务治理的方方面面,另外由于依托了 Spirng、Spirng Boot的优势之上,两个框架在开始目标就不一致,Dubbo 定位服务治理、Spirng Cloud 是一个生态。 108题 Dubbo通过Token令牌防止用户绕过注册中心直连,然后在注册中心上管理授权。Dubbo还提供服务黑白名单,来控制服务所允许的调用方。 107题 Dubbo超时时间设置有两种方式: 服务提供者端设置超时时间,在Dubbo的用户文档中,推荐如果能在服务端多配置就尽量多配置,因为服务提供者比消费者更清楚自己提供的服务特性。 服务消费者端设置超时时间,如果在消费者端设置了超时时间,以消费者端为主,即优先级更高。因为服务调用方设置超时时间控制性更灵活。如果消费方超时,服务端线程不会定制,会产生警告。 106题 Random LoadBalance: 随机选取提供者策略,有利于动态调整提供者权重。截面碰撞率高,调用次数越多,分布越均匀; RoundRobin LoadBalance: 轮循选取提供者策略,平均分布,但是存在请求累积的问题; LeastActive LoadBalance: 最少活跃调用策略,解决慢提供者接收更少的请求; ConstantHash LoadBalance: 一致性Hash策略,使相同参数请求总是发到同一提供者,一台机器宕机,可以基于虚拟节点,分摊至其他提供者,避免引起提供者的剧烈变动; 缺省时为Random随机调用。 105题 Consumer(消费者),连接注册中心 ,并发送应用信息、所求服务信息至注册中心。 注册中心根据 消费 者所求服务信息匹配对应的提供者列表发送至Consumer 应用缓存。 Consumer 在发起远程调用时基于缓存的消费者列表择其一发起调用。 Provider 状态变更会实时通知注册中心、在由注册中心实时推送至Consumer。 104题 Provider:暴露服务的服务提供方。 Consumer:调用远程服务的服务消费方。 Registry:服务注册与发现的注册中心。 Monitor:统计服务的调用次调和调用时间的监控中心。 Container:服务运行容器。 103题 主要就是如下3个核心功能: Remoting:网络通信框架,提供对多种NIO框架抽象封装,包括“同步转异步”和“请求-响应”模式的信息交换方式。 Cluster:服务框架,提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持。 Registry:服务注册,基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。 102题 透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。 101题 垂直分表定义:将一个表按照字段分成多表,每个表存储其中一部分字段。水平分表是在同一个数据库内,把同一个表的数据按一定规则拆到多个表中。 100题 垂直分库是指按照业务将表进行分类,分布到不同的数据库上面,每个库可以放在不同的服务器上,它的核心理念是专库专用。水平分库是把同一个表的数据按一定规则拆到不同的数据库中,每个库可以放在不同的服务器上。 99题 QPS:每秒查询数。TPS:每秒处理事务数。Uptime:服务器已经运行的时间,单位秒。Questions:已经发送给数据库查询数。Com_select:查询次数,实际操作数据库的。Com_insert:插入次数。Com_delete:删除次数。Com_update:更新次数。Com_commit:事务次数。Com_rollback:回滚次数。 98题 如果需要跨主机进行JOIN,跨应用进行JOIN,或者数据库不能获得较好的执行计划,都可以自己通过程序来实现JOIN。 例如:SELECT a.,b. FROM a,b WHERE a.col1=b.col1 AND a.col2> 10 ORDER BY a.col2; 可以利用程序实现,先SELECT * FROM a WHERE a.col2>10 ORDER BY a.col2;–(1) 利用(1)的结果集,做循环,SELECT * FROM b WHERE b.col1=a.col1; 这样可以避免排序,可以在程序里控制执行的速度,有效降低数据库压力,也可以实现跨主机的JOIN。 97题 搭建复制的必备条件:复制的机器之间网络通畅,Master打开了binlog。 搭建复制步骤:建立用户并设置权限,修改配置文件,查看master状态,配置slave,启动从服务,查看slave状态,主从测试。 96题 Heartbeat方案:利用Heartbeat管理VIP,利用crm管理MySQL,MySQL进行双M复制。(Linux系统下没有分库的标准方案)。 LVS+Keepalived方案:利用Keepalived管理LVS和VIP,LVS分发请求到MySQL,MySQL进行双M复制。(Linux系统下无分库无事务的方案)。 Cobar方案:利用Cobar进行HA和分库,应用程序请求Cobar,Cobar转发请求道数据库。(有分库的标准方案,Unix下唯一方案)。 95题 聚集(clustered)索引,也叫聚簇索引,数据行的物理顺序与列值(一般是主键的那一列)的逻辑顺序相同,一个表中只能拥有一个聚集索引。但是,覆盖索引可以模拟多个聚集索引。存储引擎负责实现索引,因此不是所有的存储索引都支持聚集索引。当前,SolidDB和InnoDB是唯一支持聚集索引的存储引擎。 优点:可以把相关数据保存在一起。数据访问快。 缺点:聚集能最大限度地提升I/O密集负载的性能。聚集能最大限度地提升I/O密集负载的性能。建立在聚集索引上的表在插入新行,或者在行的主键被更新,该行必须被移动的时候会进行分页。聚集表可会比全表扫描慢,尤其在表存储得比较稀疏或因为分页而没有顺序存储的时候。第二(非聚集)索引可能会比预想的大,因为它们的叶子节点包含了被引用行的主键列。 94题 以下原因是导致mysql 表毁坏的常见原因: 服务器突然断电导致数据文件损坏; 强制关机,没有先关闭mysql 服务; mysqld 进程在写表时被杀掉; 使用myisamchk 的同时,mysqld 也在操作表; 磁盘故障;服务器死机;mysql 本身的bug 。 93题 1.定位慢查询 首先先打开慢查询日志设置慢查询时间; 2.分析慢查询(使用explain工具分析sql语句); 3.优化慢查询 。
游客ih62co2qqq5ww 2020-06-15 13:55:41 0 浏览量 回答数 0

问题

支付宝的性能测试

       一、性能测试支付宝场景介绍   2013年双11过程当中,促销开启的第一分钟内支付宝的交易总额就突破了一亿元,短时间内大量用户涌入的情况下,如何保证用户的支付顺畅,...
云效平台 2019-12-01 21:47:13 5472 浏览量 回答数 1

回答

 TTS</B>是Text To Speech的缩写,即“从文本到语音”。它是同时运用语言学和心理学的杰出之作,在内置芯片的支持之下,通过神经网络的设计,把文字智能地转化为自然语音流。TTS技术对文本文件进行实时转换,转换时间之短可以秒计算。在其特有智能语音控制器作用下,文本输出的语音音律流畅,使得听者在听取信息时感觉自然,毫无机器语音输出的冷漠与生涩感。TTS语音合成技术即将覆盖国标一、二级汉字,具有英文接口,自动识别中、英文,支持中英文混读。所有声音采用真人普通话为标准发音,实现了120-150个汉字/秒的快速语音合成,朗读速度达3-4个汉字/秒,使用户可以听到清晰悦耳的音质和连贯流畅的语调。现在有少部分MP3随身听具有了TTS功能。   TTS是语音合成应用的一种,它将储存于电脑中的文件,如帮助文件或者网页,转换成自然语音输出。TTS可以帮助有视觉障碍的人阅读计算机上的信息,或者只是简单的用来增加文本文档的可读性。现在的TTL应用包括语音驱动的邮件以及声音敏感系统。TTS经常与声音识别程序一起使用。现在有很多TTS的产品,包括Read Please 2000, Proverbe Speech Unit,以及Next Up Technology的TextAloud。朗讯、 Elan、以及 AT&T都有自己的语音合成产品。   除了TTS软件之外,很多商家还提供硬件产品,其中包括以色列WizCom Technologies公司的 Quick Link Pen,它是一个笔状的可以扫描也可以阅读文字的设备;还有Ostrich Software公司的Road Runner,一个手持的可以阅读ASCII文本的设备;另外还有美国DEC公司的DecTalk TTS,它是可以替代声卡的外部硬件设备,它包含一个内部软件设备,可以与个人电脑自己的声卡协同工作。 TTS文语转换用途很广,包括电子邮件的阅读、IVR系统的语音提示等等,目前IVR系统已广泛应用于各个行业(如电信、交通运输等)。   TTS所用的关键技术就是语音合成(SpeechSynthesis)。早期的TTS一般采用专用的芯片实现,如德州仪器公司的TMS50C10/TMS50C57、飞利浦的PH84H36等,但主要用在家用电器或儿童玩具中。   而基于微机应用的TTS一般用纯软件实现,主要包括以下几部分:   ●文本分析-对输入文本进行语言学分析,逐句进行词汇的、语法的和语义的分析,以确定句子的低层结构和每个字的音素的组成,包括文本的断句、字词切分、多音字的处理、数字的处理、缩略语的处理等。   ●语音合成-把处理好的文本所对应的单字或短语从语音合成库中提取,把语言学描述转化成言语波形。   ●韵律处理-合成音质(Qualityof Synthetic Speech)是指语音合成系统所输出的语音的质量,一般从清晰度(或可懂度)、自然度和连贯性等方面进行主观评价。清晰度是正确听辨有意义词语的百分率;自然度用来评价合成语音音质是否接近人说话的声音,合成词语的语调是否自然; 连贯性用来评价合成语句是否流畅。   要合成出高质量的语音,所采用的算法是极为复杂的,因此对机器的要求也非常高。算法的复杂度决定了目前微机并发进行多通道TTS的系统容量。 在一般的CTI应用系统中,都会有IVR(交互式语音应答系统)。IVR系统是呼叫中心的重要组成部分,通过IVR系统,用户可以利用音频按健电话输入信息,从系统中获得预先录制的数字或合成语音信息。具有TTS功能的IVR可以加快服务速度,节约服务成本,使IVR为呼叫者提供7*24小时的服务。   目前常见的IVR系统大都是通用的工控机平台上插入语音板卡组成,并支持中文语音合成TTS等技术。   一个典型的包含TTS服务的电话服务流程可分为:   用户电话拨入,系统IVR响应,获得用户按键等信息。   IVR根据用户的按键信息,向数据库服务器申请相关数据。   数据库服务器返回文本数据给IVR。   IVR通过其TCP通讯接口,将需要合成的文本信息发送给TTS服务器。   TTS服务器将用户文本合成的语音数据分段通过TCP通讯接口发送给IVR服务器。   IVR服务器把分段语音数据组装成为独立的语音文件。   IVR播放相应的语音文件给电话用户。   一般的公网接入(IVR)大都采用工控机+语音板卡,而合成的语音数据则通过局域网传给IVR。这种结构只适用于简单的应用场合。 包括中文语音处理和语音合成,利用中文韵律等相关知识对中文语句进行分词、词性判断、注音、数字符号转换,语音合成通过查询中文语音库得到语音。目前中文TTS系统,比较著名的有:IBM,Microsoft,Fujitsu,科大讯飞,捷通华声等研究的系统。目前比较关键的就是中文韵律处理、符号数字、多音字、构词方面有较多的问题,需要不断研究,使得中文语音合成的自然化程度较高。  CTI技术使电信和计算机相互融合,克服了传统电信和计算机服务相对单一的缺点,将两者完美结合了起来。其应用领域非常广泛,任何需要语音、数据通信,特别是那些希望把计算机网与通信网结合起来完成语音数据信息交换的系统都会用到CTI技术。   TTS即语音合成技术(Text To Speech),它涉及声学、语言学、数学信号处理技术、多媒体技术等多个学科技术,是中文信息处理领域的一项前沿技术,实现把计算机中任意出现的文字转换成自然流畅的语音输出。   TTS在CTI系统中可以应用在IVR(交互式语音应答)服务器上,以提供语音交互式平台,为用户电话来访提供语音提示,引导用户选择服务内容和输入电话事务所需的数据,并接受用户在电话拨号键盘上输入的信息,实现对计算机数据库等信息资料的交互式访问。   在IVR中应用TTS可以自动将文本信息转换为语音文件,或者实时地将文本信息合成语音并通过电话发布。实现文本与语音自动双向转换,以达到人与系统的自动交互,随时随地为客户服务。维护人员不必再人工录音,只须将电子文档引入系统中,系统可以自动将电子文档转换为语音信息播放给客户。数据库中存放的大量数据,无需事先进行录音,能够随时根据查询条件查出并合成语音进行播报,从而大大减少了座席人员的工作负担。   那么应如何将TTS功能附加到CTI应用中呢?某些比较先进的交换平台,已经在交换机的内部实现了TTS的功能,并作为标准接口的一部分对外提供,业务开发商只需要简单的调用他们即可以在业务中使用该功能。   对于未实现TTS功能的PBX,就需要业务开发商自己去选择合适的平台,在此基础上进行二次开发,即调用所选TTS平台提供的标准接口,实现语音合成功能。   目前CTI已经成为全球发展最为迅猛的产业之一,每年以50%的速度增长,CTI如同计算机产业一样是一个金字塔形的产业链,从上到下会以至少20倍的幅度增值。TTS作为一种诱人的新技术,如果能很好的嵌入到增值业务的应用中去,必将形成一个更好的应用前景。   杭州音通软件有限公司是由国家教育部和浙江省人民政府联办并依托浙江大学而成立的高新技术公司,音通公司主要致力于计算机语音技术的研发并逐步开拓语音识别、语音流媒体传输等其它语音领域的研究。其核心技术(Intone_TTS)是具有自主知识产权的中文语音合成技术,在由浙江省科技厅组织的鉴定中被专家一致鉴定为国内领先地位,并已申请多项国家专利。   Intone_TTS是一套把文本信息转换为语音信息的开发工具包,为系统集成商、软件开发商提供了完备的接口函数和编程示例,使用户能够灵活的进行调用,并集成到其它应用系统中。接口需要语音合成运行库的支持,适合多种开发环境。开发者可以根据具体的应用场合进行选择。   它能够对所有的汉字、英文、阿拉伯数字进行语音合成;   支持繁体字及多音字的编辑;   合成效果:自然、平滑;   规范的函数调用接口,同时支持微软SAPI的调用;支持同步调用和异步调用方式;   支持PCM Wave,uLaw/aLaw Wave,ADPCM,Dialogic Vox等多种语音格式;   支持GB2312码(简体中文)、BIG5码(繁体)、UNICODE码;   支持多路通道同时合成;   支持Dialogic、东进、三汇等主流语音板卡; TTS就是Text To Speech,文本转语音,文本朗读,差不多是一个意思。在语音系统开发中经常要用到。   目前市场上的TTS很多,实现方式也各式各样,有的很昂贵,如科大讯飞,据说当初得到863计划的资助,有很高的技术;有的相对便宜,如捷通华声, InfoTalk;也有免费的,如微软的TTS产品。   相对于ASR(Automatic Speech Recognition,自动语音识别)来说,实现一个TTS产品所需要的技术难度不算大,在我看来也就是个力气活。   要是让我们来做一个能够把汉语句子朗读出来的TTS,我们会怎么做呢?   有一种最简单的TTS,就是把每个字都念出来,你会问,岂不要录制6千多个汉字的语音?幸运的是,汉语的音节很少,很多同音字。我们最多只是需要录制: 声母数×韵母数×4,(其实不是每个读音都有4声),这样算来,最多只需要录制几百个语音就可以了。   在合成的时候需要一张汉字对应拼音的对照表,汉字拼音输入法也依赖这张表,可以在网上找到,不过通常没有4声音调,大不了自己加上,呵呵,要不怎么说是力气活呢。   这样做出来的TTS效果也还可以,特别是朗读一些没有特别含义的如姓名,家庭住址,股票代码等汉语句子,听起来足够清晰。这要归功于我们伟大的母语通常都是单音节,从古代的时候开始,每个汉字就有一个词,表达一个意思。而且汉字不同于英语,英语里面很多连读,音调节奏变化很大,汉字就简单多了。   当然,你仍然要处理一些细节,比如多音字,把“银行”读成“yin xing”就不对了;再比如,标点符号的处理,数字、字母的处理,这些问题对于写过很多程序的你,当然不难了。   国内的一些语音板卡带的TTS,不管是卖钱的还是免费的,大体都是这样做出来的,也就是这样的效果。   如果要把TTS的效果弄好一点,再来点力气活,把基本的词录制成语音,如常见的两字词,四字成语等,再做个词库和语音库的对照表,每次需要合成时到词库里面找。这样以词为单位,比以字为单位,效果自然是好多了。当然,这里面还是有个技术,就是分词的技术,要把复杂的句子断成合理的词序列,也有点技术。这也要怪新文化那些先驱们,当初倡导白话文,引进西文的横排格式、标点符号的时候,没有引进西文中的空格分词。不过即使分词算法那么不高效,不那么准确,也问题不大,如前面所说,汉字是单音节词,把声音合起来,大体上不会有错。   当然,科大讯飞的力气活又干的多了些,据说已经进化到以常用句子为单位来录音了,大家可以想像,这要耗费更多的力气,换来更好的效果。   至于增加一些衔接处的“词料”,弄一些修饰性的音调,我认为是无关紧要的,对整体的效果改进不是太大。   市面上商品化TTS一般还支持粤语,请个粤语播音员录音,把上面的力气活重做一遍就是了。   再说句题外话,很多人觉得录音最好找电台、电视台的播音员,其实找个你周围的女同事来录制,只要吐字清晰就可以了。在某种情况下,寻常声音比字正腔圆的新闻联播来得可爱。   再来说说文本的标识,对于复杂文本,某些内容程序没有办法处理,需要标识出来。比如,单纯的数字“128”,是应该念成“一百二十八”还是“一二八”?解决办法通常是加入XML标注,如微软的TTS:"<context ID = "number_cardinal">128</context>"念成“一百二十八”,"<context ID = "number_digit">128</context>"将念成“一二八”。TTS引擎可以去解释这些标注。遗憾的是,语音XML标注并没有形成大家都完全认可的标准,基本上是各自一套。   再说说TTS应用编程,微软的TTS编程接口叫SAPI,是COM接口,开发起来还是有点麻烦,还好MSDN的网站上资料很全面。微软的TTS虽然免费,但其中文角色目前是个男声,声音略嫌混浊,感觉不爽。   国内一般的厂家提供API调用接口,相对比较简单,可以方便地嵌入应用程序中去。   商品化的TTS还有个并发许可限制,就是限制同时合成的并发线程数,我觉得这个限制用处不大。无论哪种TTS,都可以将文本文件转换成语音文件,供语音卡播放。大部分应用句子比较短小,一般不会超过100个汉字,合成的时间是非常短的,弄个线程专门负责合成,其它应用向该线程请求就是了,万一句子很长,把它分解成多个短句子就是了,播放的速度总是比合成的速度慢。   也很多应用是脱机合成,没有实时性要求,就更不必买多个许可了。   更多情况下,我们甚至没有必要购买TTS,比如语音开发中常见的费用催缴,拨通后播放:“尊敬的客户,您本月的费用是:212元”,前面部分对所有客户都一样,录一个语音文件就是了,而数字的合成是很简单的,你只要录制好10个数字语音,再加上十,百,千,万,再加上金钱的单位“元”。   TTS(Training+Tool+Scheme)超越计划   针对目前成长型企业遇到的人力资源问题,立体化解决人力资源瓶颈、通过企业与专家共建、实现人才强企的人力资源方向的重大智业项目。为企业培养人力资源高级管理人才,提供先进人力资源管理工具,并协助企业建立现代人力资源战略规划。通过“培训(Training)+工具(Tool)+方案(Scheme)”的办法,为企业系统解决人力资源难点问题,进而搭建科学、完善的人力资源管理体系。   TTS TIANJIN TERMINAL SURCHARGE   天津港口附加费。09年从日韩经过的船所收的一个费用 答案来源网络,供参考,希望对您有帮助
问问小秘 2019-12-02 03:05:12 0 浏览量 回答数 0

回答

您可以使用阿里云负载均衡来访问服务。 背景信息 如果您的集群的cloud-controller-manager版本大于等于v1.9.3,对于指定已有SLB,系统默认不再为该SLB处理监听,用户可以通过设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true"参数来显示启用监听配置,或者手动配置该SLB的监听规则。 执行以下命令,可查看cloud-controller-manager的版本。 root@master # kubectl get pod -n kube-system -o yaml|grep image:|grep cloud-con|uniq image: registry-vpc.cn-hangzhou.aliyuncs.com/acs/cloud-controller-manager-amd64:v1.9.3 注意事项 Cloud Controller Manager(简称CCM)会为Type=LoadBalancer类型的Service创建或配置阿里云负载均衡(SLB),包含SLB、监听、虚拟服务器组等资源。 对于非LoadBalancer类型的Service则不会为其配置负载均衡,这包含如下场景:当用户将Type=LoadBalancer的Service变更为Type!=LoadBalancer时,CCM也会删除其原先为该Service创建的SLB(用户通过service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id指定的已有SLB除外)。 自动刷新配置 CCM使用声明式API,会在一定条件下自动根据Service的配置刷新阿里云负载均衡配置,所有用户自行在SLB控制台上修改的配置均存在被覆盖的风险(使用已有SLB同时不覆盖监听的场景除外),因此不能在SLB控制台手动修改Kubernetes创建并维护的SLB的任何配置,否则有配置丢失的风险。 同时支持为serivce指定一个已有的负载均衡,或者让CCM自行创建新的负载均衡。但两种方式在SLB的管理方面存在一些差异: 指定已有SLB 仅支持复用负载均衡控制台创建的SLB,不支持复用CCM创建的SLB。 如果您需要在Kubernetes集群中复用私网类型的SLB,则该SLB需要和Kubernetes集群在同一VPC下。 需要为Service设置annotation:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id 。 SLB配置 此时CCM会使用该SLB做为Service的SLB,并根据其他annotation配置SLB,并且自动的为SLB创建多个虚拟服务器组(当集群节点变化的时候,也会同步更新虚拟服务器组里面的节点)。 监听配置 是否配置监听取决于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: 是否设置为true。如果设置为false,CCM不会为SLB管理任何监听配置;如果设置为true,CCM会根据service配置管理监听,如果监听已经存在,则CCM会覆盖已有监听。 SLB的删除 当Service删除时CCM不会删除用户通过id指定的已有SLB。 CCM管理的SLB CCM会根据Service的配置自动的创建配置SLB、监听、虚拟服务器组等资源,所有资源归CCM管理,因此用户不得手动在SLB控制台更改以上资源的配置,否则CCM在下次Reconcile的时候将配置刷回Service所声明的配置,造成非用户预期的结果。 SLB的删除 当Service删除时CCM会删除该SLB。 后端服务器更新 CCM会自动的为该Service对应的SLB刷新后端虚拟服务器组。当Service对应的后端Endpoint发生变化的时候或者集群节点变化的时候都会自动的更新SLB的后端Server。 spec.externalTrafficPolicy = Cluster模式的Service,CCM默认会将所有节点挂载到SLB的后端(使用BackendLabel标签配置后端的除外)。由于SLB限制了每个ECS上能够attach的SLB的个数(quota),因此这种方式会快速的消耗该quota,当quota耗尽后,会造成Service Reconcile失败。解决的办法,可以使用Local模式的Service。 spec.externalTrafficPolicy = Local模式的Service,CCM默认只会将Service对应的Pod所在的节点加入到SLB后端。这会明显降低quota的消耗速度。同时支持四层源IP保留。 任何情况下CCM不会将Master节点作为SLB的后端。 CCM默认不会从SLB后端移除被kubectl drain/cordon的节点。如需移除节点,请设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend为on。 说明 如果是v1.9.3.164-g2105d2e-aliyun之前的版本,CCM默认会从SLB后端移除被kubectl drain/cordon的节点。 VPC路由 集群中一个节点对应一条路由表项,VPC默认情况下仅支持48条路由表项,如果集群节点数目多于48个,请提工单给VPC产品。 说明 您可以在提交工单时,说明需要修改vpc_quota_route_entrys_num参数,用于提升单个路由表可创建的自定义路由条目的数量。 更多VPC使用限制请参见使用限制。 专有网络VPC配额查询请参见专有网络VPC配额管理。 SLB使用限制 CCM会为Type=LoadBalancer类型的Service创建SLB。默认情况下一个用户可以保留60个SLB实例,如果需要创建的SLB数量大于60,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_instances_num参数,用于提高用户可保有的slb实例个数。 CCM会根据Service将ECS挂载到SLB后端服务器组中。 默认情况下一个ECS实例可挂载的后端服务器组的数量为50个,如果一台ECS需要挂载到更多的后端服务器组中,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_backendservers_num参数,用于提高同一台服务器可以重复添加为SLB后端服务器的次数。 默认情况下一个SLB实例可以挂载200个后端服务器,如果需要挂载更多的后端服务器,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_backendservers_num参数,提高每个SLB实例可以挂载的服务器数量。 CCM会根据Service中定义的端口创建SLB监听。默认情况下一个SLB实例可以添加50个监听,如需添加更多监听,请提交工单给SLB产品。 说明 您可以在提交工单时,说明需要修改slb_quota_listeners_num参数,用于提高每个实例可以保有的监听数量。 更多SLB使用限制请参见使用限制。 负载均衡SLB配额查询请参见负载均衡SLB配额管理。 通过命令行操作 方法一: 通过命令行工具创建一个Nginx应用。 root@master # kubectl run nginx --image=registry.aliyuncs.com/acs/netdia:latest root@master # kubectl get po NAME READY STATUS RESTARTS AGE nginx-2721357637-dvwq3 1/1 Running 1 6s 为Nginx应用创建阿里云负载均衡服务,指定 type=LoadBalancer 来向外网用户暴露Nginx服务。 root@master # kubectl expose deployment nginx --port=80 --target-port=80 --type=LoadBalancer root@master # kubectl get svc NAME CLUSTER-IP EXTERNAL-IP PORT(S) AGE nginx 172.19.XX.XX 101.37.XX.XX 80:31891/TCP 4s 在浏览器中访问 http://101.37.XX.XX,来访问您的Nginx服务。 方法二: 将下面的yml code保存到 nginx-svc.yml文件中。 apiVersion: v1 kind: Service metadata: labels: run: nignx name: nginx-01 namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 执行如下命令,创建一个Nginx应用。 kubectl apply -f nginx-svc.yml 执行如下命令,向外网用户暴露Nginx服务。 root@master # kubectl get service NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE9d ngi-01nx LoadBalancer 172.19.XX.XX 101.37.XX.XX 80:32325/TCP 3h 在浏览器中访问 http://101.37.XX.XX,来访问您的Nginx服务。 通过 Kubernetes Dashboard 操作 将下面的yml code保存到 nginx-svc.yml文件中。 apiVersion: v1 kind: Service metadata: labels: run: nginx name: http-svc namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 登录容器服务管理控制台,单击目标集群右侧的控制台,进入Kubernetes Dashboard页面。 单击创建,开始创建应用。 创建应用 单击使用文件创建。选择刚才保存的nginx-svc.yml 文件。 单击上传。 此时,会创建一个阿里云负载均衡实例指向创建的Nginx应用,服务的名称为 http-svc。 在Kubernetes Dashboard上定位到default命名空间,选择服务。 可以看到刚刚创建的 http-svc 的Nginx服务和机器的负载均衡地址 http://114.55.XX.XX:80。 访问服务 将该地址拷贝到浏览器中即可访问该服务。 通过控制台操作 登录容器服务管理控制台。 在 Kubernetes 菜单下,单击左侧导航栏中的应用 > 无状态,进入无状态(Deployment)页面。 选择目标集群和命名空间,单击右上角使用模板创建。 创建应用 示例模板选为自定义,将以下内容复制到模板中。 apiVersion: v1 kind: Service metadata: labels: run: nginx name: ngnix namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 单击创建。 创建成功,单击Kubernetes 控制台前往控制台查看创建进度。 Kubernetes 控制台 或单击左侧导航栏路由与负载均衡 > 服务,选择目标集群和命名空间,查看已部署的服务。 部署服务 更多信息 阿里云负载均衡还支持丰富的配置参数,包含健康检查、收费类型、负载均衡类型等参数。 注释 阿里云可以通过注释annotations的形式支持丰富的负载均衡功能。 创建一个公网类型的负载均衡 apiVersion: v1 kind: Service metadata: name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建一个私网类型的负载均衡 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建HTTP类型的负载均衡 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建HTTPS类型的负载均衡 需要先在阿里云控制台上创建一个证书并记录cert-id,然后使用如下annotation创建一个 HTTPS 类型的SLB。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 限制负载均衡的带宽 只限制负载均衡实例下的总带宽,所有监听共享实例的总带宽,参见共享实例带宽。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: "paybybandwidth" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: "100" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 指定负载均衡规格 负载均衡规格可参见CreateLoadBalancer。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec: "slb.s1.small" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用已有的负载均衡 默认情况下,使用已有的负载均衡实例,不会覆盖监听,如要强制覆盖已有监听,请配置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners为true。 说明 复用已有的负载均衡默认不覆盖已有监听,因为以下两点原因: 如果已有负载均衡的监听上绑定了业务,强制覆盖可能会引发业务中断。 由于CCM目前支持的后端配置有限,无法处理一些复杂配置。如果有复杂的后端配置需求,可以在不覆盖监听的情况下,通过控制台自行配置监听。 如存在以上两种情况不建议强制覆盖监听,如果已有负载均衡的监听端口不再使用,则可以强制覆盖。 使用已有的负载均衡暂不支持添加额外标签(annotation: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags) apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALACER_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用已有的负载均衡,并强制覆盖已有监听 强制覆盖已有监听,如果监听端口冲突,则会删除已有监听。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id: "${YOUR_LOADBALACER_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners: "true" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 使用指定Label的worker节点作为后端服务器 多个Label以逗号分隔。例如"k1=v1,k2=v2"。多个label之间是and的关系。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-backend-label: "failure-domain.beta.kubernetes.io/zone=ap-southeast-5a" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为TCP类型的负载均衡配置会话保持时间 参数service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-time仅对TCP协议的监听生效。 如果负载均衡实例配置了多个TCP协议的监听端口,则默认将该配置应用到所有TCP协议的监听端口。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-timeout: "1800" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为HTTP&HTTPS协议的负载均衡配置会话保持(insert cookie) 仅支持HTTP及HTTPS协议的负载均衡实例。 如果配置了多个HTTP或者HTTPS的监听端口,该会话保持默认应用到所有HTTP和HTTPS监听端口。 配置insert cookie,以下四项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type: "insert" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie-timeout: "1800" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为HTTP&HTTPS协议的负载均衡配置会话保持(server cookie) 仅支持HTTP及HTTPS协议的负载均衡实例。 如果配置了多个HTTP或者HTTPS的监听端口,该会话保持默认应用到所有HTTP和HTTPS监听端口。 配置server cookie,以下四项annotation必选。 cookie名称(service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie)只能包含字母、数字、‘_’和‘-’。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type: "server" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie: "${YOUR_COOKIE}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建负载均衡时,指定主备可用区 某些region的负载均衡不支持主备可用区,例如ap-southeast-5。 一旦创建,主备可用区不支持修改。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid: "ap-southeast-5a" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid: "ap-southeast-5a" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 使用Pod所在的节点作为后端服务器 默认externalTrafficPolicy为Cluster模式,会将集群中所有节点挂载到后端服务器。Local模式仅将Pod所在节点作为后端服务器。 Local模式需要设置调度策略为加权轮询wrr。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler: "wrr" name: nginx namespace: default spec: externalTrafficPolicy: Local ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 创建私有网络类型(VPC)的负载均衡 创建私有网络类型的负载均衡,以下两个annotation必选。 私网负载均衡支持专有网络(VPC)和经典网络(Classic),两者区别参见实例概述。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-network-type: "vpc" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 创建按流量付费的负载均衡 仅支持公网类型的负载均衡实例 以下两项annotation必选 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth: "45" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type: "paybybandwidth" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 创建带健康检查的负载均衡 设置TCP类型的健康检查 TCP端口默认开启健康检查,且不支持修改,即service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag annotation无效。 设置TCP类型的健康检查,以下所有annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "tcp" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout: "8" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 设置HTTP类型的健康检查 设置HTTP类型的健康检查,以下所有的annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type: "http" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri: "/test/index.html" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold: "4" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout: "10" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval: "3" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "http:80" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为负载均衡设置调度算法 rr(默认值):轮询,按照访问顺序依次将外部请求依序分发到后端服务器。 wrr:加权轮询,权重值越高的后端服务器,被轮询到的次数(概率)也越高。 wlc:加权最小连接数,除了根据每台后端服务器设定的权重值来进行轮询,同时还考虑后端服务器的实际负载(即连接数)。当权重值相同时,当前连接数越小的后端服务器被轮询到的次数(概率)也越高。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler: "wlc" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡配置访问控制策略组 需要先在阿里云负载均衡控制台上创建一个负载均衡访问控制策略组,然后记录该访问控制策略组ID(acl-id),然后使用如下annotation创建一个带有访问控制的负载均衡实例。 白名单适合只允许特定IP访问的场景,black黑名单适用于只限制某些特定IP访问的场景。 使用该功能前,请确保CloudControllerManage组件是最新版本。请登录容器服务管理控制台,在左侧导航栏选择集群 > 集群,在集群列表中对需要升级的集群单击更多 > 系统组件升级,在组件列表中找到Cloud Controller Manager,单击升级。系统组建升级 创建带有访问控制的负载均衡,以下三项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-status: "on" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-id: "${YOUR_ACL_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-type: "white" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡指定虚拟交换机 通过阿里云专有网络控制台查询交换机ID,然后使用如下的annotation为负载均衡实例指定虚拟交换机。 为负载均衡指定虚拟交换机,以下两项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type: "intranet" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vswitch-id: "${YOUR_VSWITCH_ID}" name: nginx namespace: default spec: ports: - port: 443 protocol: TCP targetPort: 443 selector: run: nginx type: LoadBalancer 为负载均衡指定转发端口 端口转发是指将http端口的请求转发到https端口上。 设置端口转发需要先在阿里云控制台上创建一个证书并记录cert-id。 如需设置端口转发,以下三项annotation必选。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port: "https:443,http:80" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id: "${YOUR_CERT_ID}" service.beta.kubernetes.io/alibaba-cloud-loadbalancer-forward-port: "80:443" name: nginx namespace: default spec: ports: - name: https port: 443 protocol: TCP targetPort: 443 - name: http port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 为负载均衡添加额外标签 多个tag以逗号分隔,例如"k1=v1,k2=v2"。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags: "Key1=Value1,Key2=Value2" name: nginx namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: run: nginx type: LoadBalancer 移除SLB后端unscheduleable状态的节点 kubectl cordon与kubectl drain命令会将节点置为unscheduleable状态,默认service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend的取值为off,此时不会将处于unscheduleable状态的节点从SLB的后端服务器组移除。若需要从SLB的后端服务器组移除unscheduleable状态的节点,请将service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend的的取值设置为on。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend: "on" name: nginx spec: externalTrafficPolicy: Local ports: - name: http port: 30080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 直接将Pod ENI挂载到SLB后端 支持在Terway 网络模式下,通过annotation:service.beta.kubernetes.io/backend-type:"eni" 将Pod直接挂载到SLB后端,提升网络转发性能。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/backend-type: "eni" name: nginx spec: ports: - name: http port: 30080 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 创建IPv6类型的负载均衡 集群的kube-proxy代理模式需要是IPVS。 生成的IPv6地址仅可在支持IPv6的环境中访问。 创建后IP类型不可更改。 apiVersion: v1 kind: Service metadata: annotations: service.beta.kubernetes.io/alibaba-cloud-loadbalancer-ip-version: "ipv6" name: nginx spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: nginx type: LoadBalancer 说明 注释的内容是区分大小写的。 自2019年9月11日起,annotation字段alicloud更新为alibaba-cloud。 例如: 更新前:service.beta.kubernetes.io/alicloud-loadbalancer-id 更新后:service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id 系统将继续兼容alicloud的写法,用户无需做任何修改,敬请注意。 注释 类型 描述 默认值 支持的版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-protocol-port string 多个值之间由逗号分隔,例如:https:443,http:80 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type string 取值可以是internet或者intranet internet v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slb-network-type string 负载均衡的网络类型,取值可以是classic或者vpc 取值为vpc时,需设置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-address-type为intranet。 classic v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-charge-type string 取值可以是paybytraffic或者paybybandwidth paybytraffic v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id string 负载均衡实例的 ID。通过 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-id指定您已有的SLB,默认情况下,使用已有的负载均衡实例,不会覆盖监听,如要强制覆盖已有监听,请配置service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners为true。 无 v1.9.3.81-gca19cd4-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-backend-label string 通过 label 指定 SLB 后端挂载哪些worker节点。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-spec string 负载均衡实例的规格。可参见:CreateLoadBalancer 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-persistence-timeout string 会话保持时间。 仅针对TCP协议的监听,取值:0-3600(秒) 默认情况下,取值为0,会话保持关闭。 可参见:CreateLoadBalancerTCPListener 0 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session string 是否开启会话保持。取值:on | off 说明 仅对HTTP和HTTPS协议的监听生效。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener off v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type string cookie的处理方式。取值: insert:植入Cookie。 server:重写Cookie。 说明 仅对HTTP和HTTPS协议的监听生效。 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session取值为on时,该参数必选。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie-timeout string Cookie超时时间。取值:1-86400(秒) 说明 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session为on且service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type为insert时,该参数必选。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cookie string 服务器上配置的Cookie名称。 长度为1-200个字符,只能包含ASCII英文字母和数字字符,不能包含逗号、分号或空格,也不能以$开头。 说明 当service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session为on且service.beta.kubernetes.io/alibaba-cloud-loadbalancer-sticky-session-type为server时,该参数必选。 可参见:CreateLoadBalancerHTTPListener和CreateLoadBalancerHTTPSListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-master-zoneid string 主后端服务器的可用区ID。 无 v1.9.3.10-gfb99107-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-slave-zoneid string 备后端服务器的可用区ID。 无 v1.9.3.10-gfb99107-aliyun及以上版本 externalTrafficPolicy string 哪些节点可以作为后端服务器,取值: Cluster:使用所有后端节点作为后端服务器。 Local:使用Pod所在节点作为后端服务器。 Cluster v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-force-override-listeners string 绑定已有负载均衡时,是否强制覆盖该SLB的监听。 false:不覆盖 v1.9.3.81-gca19cd4-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-bandwidth string 负载均衡的带宽,仅适用于公网类型的负载均衡。 50 v1.9.3.10-gfb99107-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-cert-id string 阿里云上的证书ID。您需要先上传证书 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-flag string 取值是on | off TCP监听默认为on且不可更改。 HTTP监听默认为off。 默认为off。TCP 不需要改参数。因为 TCP 默认打开健康检查,用户不可设置。 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-type string 健康检查类型,取值:tcp | http。 可参见:CreateLoadBalancerTCPListener tcp v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-uri string 用于健康检查的URI。 说明 当健康检查类型为TCP模式时,无需配置该参数。 可参见:CreateLoadBalancerTCPListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-port string 健康检查使用的端口。取值: -520:默认使用监听配置的后端端口。 1-65535:健康检查的后端服务器的端口。 可参见:CreateLoadBalancerTCPListener 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-healthy-threshold string 健康检查连续成功多少次后,将后端服务器的健康检查状态由fail判定为success。 取值:2-10 可参见:CreateLoadBalancerTCPListener 3 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-unhealthy-threshold string 健康检查连续失败多少次后,将后端服务器的健康检查状态由success判定为fail。取值: 2-10 可参见:CreateLoadBalancerTCPListener 3 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval string 健康检查的时间间隔。 取值:1-50(秒) 可参见:CreateLoadBalancerTCPListener 2 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout string 接收来自运行状况检查的响应需要等待的时间,适用于TCP模式。如果后端ECS在指定的时间内没有正确响应,则判定为健康检查失败。 取值:1-300(秒) 说明 如果service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout的值小于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值,则service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-connect-timeout无效,超时时间为service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值。 可参见:CreateLoadBalancerTCPListener 5 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout string 接收来自运行状况检查的响应需要等待的时间,适用于HTTP模式。如果后端ECS在指定的时间内没有正确响应,则判定为健康检查失败。 取值:1-300(秒) 说明 如果 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout的值小于service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值,则 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-timeout无效,超时时间为 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-interval的值。 可参见:CreateLoadBalancerTCPListener 5 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-domain string 用于健康检查的域名。 $_ip:后端服务器的私网IP。当指定了IP或该参数未指定时,负载均衡会使用各后端服务器的私网IP当做健康检查使用的域名。 domain:域名长度为1-80,只能包含字母、数字、点号(.)和连字符(-)。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-health-check-httpcode string 健康检查正常的HTTP状态码,多个状态码用逗号(,)分割。取值: http_2xx http_3xx http_4xx http_5xx 默认值为http_2xx。 http_2xx v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-scheduler string 调度算法。取值wrr | wlc| rr。 wrr:权重值越高的后端服务器,被轮询到的次数(概率)也越高。 wlc:除了根据每台后端服务器设定的权重值来进行轮询,同时还考虑后端服务器的实际负载(即连接数)。当权重值相同时,当前连接数越小的后端服务器被轮询到的次数(概率)也越高。 rr:默认取值,按照访问顺序依次将外部请求依序分发到后端服务器。 rr v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-status string 是否开启访问控制功能。取值: on | off off v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-id string 监听绑定的访问策略组ID。当AclStatus参数的值为on时,该参数必选。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-acl-type string 访问控制类型。 取值:white | black。 white:仅转发来自所选访问控制策略组中设置的IP地址或地址段的请求,白名单适用于应用只允许特定IP访问的场景。设置白名单存在一定业务风险。一旦设名单,就只有白名单中的IP可以访问负载均衡监听。如果开启了白名单访问,但访问策略组中没有添加任何IP,则负载均衡监听会转发全部请求。 black: 来自所选访问控制策略组中设置的IP地址或地址段的所有请求都不会转发,黑名单适用于应用只限制某些特定IP访问的场景。如果开启了黑名单访问,但访问策略组中没有添加任何IP,则负载均衡监听会转发全部请求。当AclStatus参数的值为on时,该参数必选。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-vswitch-id string 负载均衡实例所属的VSwitch ID。设置该参数时需同时设置addresstype为intranet。 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-forward-port string 将HTTP请求转发至HTTPS指定端口。取值如80:443 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-additional-resource-tags string 需要添加的Tag列表,多个标签用逗号分隔。例如:"k1=v1,k2=v2" 无 v1.9.3及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-remove-unscheduled-backend string 从slb后端移除SchedulingDisabled Node。取值on | off off v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/backend-type string 支持在Terway eni网络模式下,通过设定改参数为"eni",可将Pod直接挂载到SLB后端,提升网络转发性能。取值:eni。 无 v1.9.3.164-g2105d2e-aliyun及以上版本 service.beta.kubernetes.io/alibaba-cloud-loadbalancer-ip-version string 负载均衡实例的IP版本,取值:ipv4或ipv6 ipv4 v1.9.3.220-g24b1885-aliyun及以上版本
1934890530796658 2020-03-31 15:26:42 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT