三台服务器, 将安装包上传到对应的服务器上, 继续按照指引安装, 在每台服务 器上启动节点, 就可以组成一个区块链网络。 一键部署工具: 降低FISCO BCOS部署难度 区块链扩容支持: 提供FISCO BCOS区块链快速扩容支持 JAVA安装：FISCO BCOS中需要使用Oracle JDK 1.8(java 1.8)环境，提供 FISCO BCOS支持的JAVA组件 物料包搭建FISCO BC BCOS之间存在版本对应关系: 物料包1.2.X版本对应支持FISCO BCOS的版本为: 1.3.X，即物料包1.2的版 本兼容支持FISCO BCOS1.3的版本 物料包的相关流程如下: 环境依赖 部署区块链 扩容节点 部署区块链sample FISCO BCOS docker JAVA安装 物料包web3sdk配置 CheckList 日志清理脚本rmlogs.sh 节点监控脚本monitor.sh FAQ 创建一条新的区块链链的安装包 expand : 根据config.ini配置文件, 创建已经存在的区块链的扩容的安装包 -b : 根据config.ini配置文件, 创建一条新的区块链链的安装包, 可以与-p,-c,- d参数配合使用 -e : 根据config.ini配置文件, 创建已经存在的区块链的扩容的安装包, 可以 与-p,-c,-d参数配合使用 -p : 指定使用fisco-bcos的路径,适用

大纲 • 产品发展中遇到的问题 • 异地多活存在哪些挑战 • 讯飞输入法异地多活解决方案 • 实际应用效果 • 未来规划 单机房遇到的问题 可用性低 响应时间慢 系统扩容难 可用性低 响应时间慢 系统扩容难 大纲 • 产品发展中遇到的问题 • 异地多活存在哪些技术挑战 • 讯飞输入法解决方案 • 实际应用效果 • 后续规划 技术挑战 几十毫秒的延迟； 跨机房性能较慢 Hadoop ES Spark kafka Web Web 专线/公网 容量合理规划 客户端 北京 50% 合肥 50% 广州 50% 1 1 2 冗余机器与其他系统复用，弹性伸缩 配套系统支撑 测试场景覆盖 灰度发布上线 机房流量调度 监控覆盖 故障模拟演练 数据恢复 配置平台 服务化平台 日常运维 大纲 • 产品发展中遇到的问题 • 异地多活存在哪些技术挑战 几乎无劫持，延迟降低 20%，解析失败率率下 降15% 响应时间 优化前 优化后 系统扩容 北京IDC 合肥IDC 广州IDC 系统能够任意水平扩容 大纲 • 产品发展中遇到的问题 • 异地多活存在哪些技术挑战 • 讯飞输入法解决方案 • 应用实践以及经验教训 • 未来规划 未来规划 • 异地多活架构平台化 • 弹性伸缩完善 • 一致性要求较高场景 • 西部以及海外机房部署 Q & A

在服务的可用性方面，我们对接入的服务进行了鉴权，保证服务的安全可靠，部分核心行为，我们做了物 理上的隔离，保证行为数据之间不会相互影响，同时接入了公司内部基于Docker的容器管理和可伸缩平 台HULK，能做到自动扩容。对于数据使用有严格权限审计，并且做了相关数据脱敏工作。 监控 监控 从用户行为数据的产生，到收集分发，到最后的处理，我们都做到了相关的监控，比如因为我们的代码改 动，发生处理时长变长，我们可 美团容器平台架构及容器技术实践 美团容器平台架构及容器技术实践 作者: 欧阳坚 背景 背景 美团的容器集群管理平台叫做HULK。漫威动画里的HULK在发怒时会变成“绿巨人”，它的这个特性和容 器的“弹性伸缩”很像，所以我们给这个平台起名为HULK。貌似有一些公司的容器平台也叫这个名字，纯 属巧合。 2016年，美团开始使用容器，当时美团已经具备一定的规模，在使用容器之前就已经存在的各种系统， 容器平台进行了一次升级，这就是容器集群管理平台HULK 2.0。 把基于OpenStack的调度系统升级成容器编排领域的事实标准Kubernetes（以后简称K8s）。 提供了更丰富可靠的容器弹性策略。 针对之前在基础系统上碰到的一些问题，进行了优化和打磨。 美团的容器使用状况是：目前线上业务已经超过3000个服务，容器实例数超过30000个，很多大并发、 低延时要求的核心链路服务，已

过载保护 丢车保帅 容量水位线 底线 多节点有序参与 智能DNS，DNS负载均衡 限流(limit,lua)，openresty，4层/7层LB 弹性扩容，限流(token)，熔断，防刷 降级，熔断，弹性扩容 多IDC，区域容灾，多ISP 集群，高可用，分片 本地缓存，防刷，流控 终端 域名 机房 LB / NG.. 网关 Cache 服务 抓大不能放小[细节决定成败]

GPUHashTable。究 其原因，主要是因为实际业务场景中，大规模稀疏特征的总量通常是未知的，并且随 时可能出现特征交叉，从而致使稀疏特征的总量变化很大，这就导致“动态扩容”能 力将成为我们 GPU HashTable 的必备功能，能够做到动态扩容的只有 cuCollec- tions 的实现。我们在 cuCollections 的 GPU HashTable 基础上实现了特殊接口 （find_or_ 的），作业积压是系统设计时必须考虑的问题。如何在有限的资源下，尽可能提高作 后端 < 915 业的吞吐能力，同时降低在资源不足情况时造成对核心业务场景的影响。 ● 如果只依靠动态扩容，容易出现资源不足时无法扩容、作业排队等待的情况。 特别是对于依赖流水线做研发卡控的业务，这会直接阻塞业务的上线流程。 ● 出于执行耗时的考虑，大部分资源采用预部署的方式，缩短资源申请和应用启 动的准备 同资源类型的配额和利用率问题。 ○ 预置的公共资源，这部分资源会提前在资源池上扩容出来，主要应对业务高 频使用的且对时间敏感的组件作业。在资源配额和利用率上，根据资源池的 历史情况和实时监控，动态调整不同资源池的大小。 ○ 按需使用的资源，主要针对公共资源环境不满足的情况，业务需要自定义资 源环境，考虑到这部分作业的体量不大，直接采用实时扩容的方式，相比预 置资源的方式，可以获得更好的资源利用率。

试点实施 效果评估 经验固化 目标设定 培 训 （ 理 论 、 案 例 、 实 战 演 练 ） 应用管理平台（CAS） 生命周期管理 部署/卸载 启动/停止 升级/回滚 灰度发布 弹性伸缩 微服务运维 应用告警 日志分析 全链路拓扑 SQL分析 调用链 立体监控 方法追踪 事务洞察 微服务治理 负载均衡 限流/降级 熔断/容错 错误注入 黑白名单 微服务管理 Mesher 统计报表服务 微服务注册中心 灵活扩展 应用零改造 微服务化 快速迭代，加 快上线速度 非侵入式接入微服务 PHP应用接入微服务治理 “更新就停机”变为 “随时更新维护” 弹性伸缩，成本可控 提升整体性能 servicecomb.apache.org github.com/apache?q=servicecomb 应用 市场 游戏中 心 视频 阅读 音乐 天际通 华为音乐传统单体架构拆解成15+个微服务，基于CSE开发和治理 • 传统单体架构升级、维护、扩容成本高 • 架构不统一，有使用SpringCloud、Dubbo、Servlet等各 种架构，维护成本非常高 大系统小做缩短上线周期 • 快速、小批量交付价值需求 • 上线周期： 月 -> 周/天 动态自治降运维成本 • 弹性伸缩、故障自动迁移、 降级熔断，提升复杂分布 式系统运维效率 华为消费者云服务全微服务化的基础底座，

资回报最大化。  以智能化，可持续发展思路，打造车企C2B2C用户体验优化闭环。  可配置适应业务生长，帮助企业更快速、灵活地应对不断变化的市场需求，随时调整业务模式快速配置，以最低成本适应弹性的数据需求。 • 主机厂/经销商、线上/线下线索管 理集中化 • 线索/会员/车主服务集中化 • 数据集中化 集中化 • 用户体验能力标准化 • 外部接口标准化 • 营销能力标准化、营销形式个性化 日志可视化 （华为云） CDN/ WAF 资源监控预警 （华为云 AOM） 营销平台 接口服务 消息 REST NAT网关 NAT gateway 4核8G 按需扩容 4核8G 按需扩容 Nginx 按需扩容 My SQL 高 可 用 安全组隔离 安全组隔离 安全组隔离 ELB C端流量 8 github.com/apache?q=servicecomb servicecomb

ZAB 协议，由于是单点写，在集群扩展性上不具备优势。Eureka 在协议上来说理论上 可以扩展到很大规模，因为都是点对点的数据同步，但是从我们对 Eureka 的运维经验来看， Eureka 集群在扩容之后，性能上有很大问题。 集群扩展性的另⼀个方面是多地域部署和容灾的支持。当讲究集群的高可用和稳定性以及网络上的 跨地域延迟要求能够在每个地域都部署集群的时候，我们现有的方案有多机房容灾、异地多活、多 资源，运维人员只需声明业 务应用所期望的资源状态即可，由 Kubernetes 调度器自动分配节点。这种自动化运维方式不仅可 以减轻运维部署的负担，而且增加了业务运行时的弹性。 Kubernetes 在应用打包、部署、调度和弹性领域是绝对的王者，吸引了无数互联网公司开启了应用 容器化改造之旅。在这迁移过程中，人们渐渐发现虽然服务运行时的底层依赖可以切换到 Kuberne tes 平台，但整个 211 > Nacos 最佳实践 Sync 服务器两次扩容 方案实现后，上了 FAT 环境上后没发现问题（此环境，很多业务服务只部署⼀个实例），而在 PROD 环境上发现存在双向同步丢心跳的问题，原因是同步服务器来不及执行排队的心跳线程，导 致 Nacos 服务器无法及时收到心跳而把业务服务踢下来。我们从 8 台 4C 8G 同步服务器扩容到 12 台，情况好了很多，但观察下来，还是存在⼀天

别严格， 如果出现配置下发不及时，或下发配置失败，极大可能出现故障，同时负载均衡服 务弹性能力的要求较高，在业务高峰如果不能快速扩容，容易出现全网故障 传统配置下发方式 负载均衡配置固话在配置文件中， 节点操作需要人工上系统操作增减 节点 配置中心监听方式 客户端主动监听配置更新，配置秒 级生效，新扩容服务主动拉取全量 配置，流量接入时长缩短3分钟+ 配置名字服务 配置IP方式 服务端下发文件更新配置，更新配 服务端下发文件更新配置，更新配 置生效时间长，由于需要预先知道 负责均衡集群的机器信息，扩缩容 需要等元信息同步以后才能接入流 量，扩容流量接入时间长 负载均衡节点对接名字服务 虎牙负载均衡部署的机器一台机器上可能存在数百的配置，每次节点生效需要重新 reload配置，且节点新增或删除需人工上系统操作配置，配置生效对服务会有中断 配置IP方式 配置名字服务 客户端主动监听名字服务更新，节 点变更秒级生效

超级链监管机制 14.1. 监管机制概述 14.2. 监管机制使用说明 15. 多盘散列 15.1. 背景 15.2. LevelDB数据模型分析 15.3. 核心改造点 15.4. 使用方式 15.5. 扩容问题 15.6. 实验 16. 平行链与群组 16.1. 背景 16.2. 术语 16.3. 架构 16.4. 设计思路 17. 超级链跨链技术 17.1. 背景 17.2. 什么是跨链 17 Options； 如果要使用多盘存储，调用者需要设置 Options.DataPaths 参数，它 是一个[]string 数组，声明了各个盘的文件夹路径，可参考 配置多盘存储 。 15.5. 扩容问题 假设本来是N块盘，扩容后是(N+M)块盘。对于已有的sst文件，因为取模的底 数变了， 可能会出现按照原有的取模散列不命中的情况。 规则是： 对于读Open，先按照 (N+M) 取模去Open，如果不存在，则遍历各盘直到 编号是唯一且递增的，所以不存在读取脏数据的问题； 对于写Open，就按照 (N+M) 取模，因为写Open一定是生成新的文件。 随着Compact的不断进行，整个数据文件的分布会越来越趋向于均匀分布在 (N+M) 个盘，扩容完成。 15.6. 实验 写入测试可参考代码 kv/mstorage/test/test_write.go [https://github.com/xuperchain/xuperchain/