ucc

作者 | 郭浩（项升） 阿里巴巴经济体 RPC 框架负责人 **导读：**本文整理自作者于 2020 年云原生微服务大会上的分享《Dubbo3.0 - 开启下一代云原生微服务》，主要介绍了关于思考 rpc 框架层面，功能演进的方向是什么？以及怎么更好地支持云上的多语言开发的新思考。 关注阿里巴巴云原生公众号，后台回复 【818】 即可获取直播回看地址和大会 PPT 合集。 看到这个题目，大家可能会有几个问题，比如，什么是云原生微服务？Dubbo3.0 是什么？和目前的 Dubbo2.0 有什么区别？用了 Dubbo3.0 会带来哪些业务视角的好处？后面的分享会对这些问题逐一解答。 这次分享分为以下几个环节： Dubbo 的演进历史 Dubbo 的开源现状 定义 Dubbo3.0 分享 Dubbo 3.0 目前取得的一些成果 考虑到有些同学对 Dubbo 可能不太熟悉，在介绍背景之前，我先简单介绍一下 Dubbo 是什么。简单地说，Dubbo 是基于 Java 的 RPC 框架。一个 RPC 框架至少由数据格式、传输协议和连接管理组成，这三点也是构成核心。Dubbo 能够被广泛应用主要有两个原因： 一方面是较好的插件机制支撑了多种扩展，这些扩展在不同业务场景和基础架构中能分别发挥最大优势； 另一方面不同于普通的 RPC 框架，Dubbo 的服务治理功能让其在易用性方面脱颖而出

6月9日， 在2020阿里云线上峰会上阿里云混合云战略正式发布：全栈建云、智能管云、极致用云。同步发布专有云敏捷版（Apsara Stack Agility）、 混合云管理平台（Apsara Uni-manager）以及下一代企业级一站式DevOps平台“云效”三大新品。阿里云智能资深技术专家王小瑞对混合云管理平台（Apsara Uni-manager）进行了详细解读。 新时代下企业客户数字化转型面临的挑战 早期企业在做数字化转型时开发的应用程序面向的用户规模非常小，例如银行、电信行业开发的应用程序主要面向柜台操作人员，而柜台的数量是有限的，所以他们面向的用户规模也有限。最近十年移动浪潮的来临，让每个人的手机都成为一个柜台，此时企业开发的应用面向的用户规模就发生翻天覆地的变化，呈现几个数量级的增长。而随着虚拟化、容器等新技术的发展，企业的IT基础设施也发生了翻天覆地的变化，开始从传统架构全面转向云架构，多云架构被越来越多的企业所认可并采用。 Gartner的报告显示：2020年，90%的中大型企业将利用混合云管理基础设施；IDC认为：未来混合云将占据整个云市场份额的67%。 为什么众多企业会选择“混合云”呢？我们认为主要原因有三点：第一中大型企业都有自己的数据中心，混合云可以帮助企业“利旧”，进行成本分摊。第二企业会有一些敏感数据需要在私有数据中心处理，特别是金融行业的企业还存在

这篇故事围绕着一款 App 基于 mPaaS 小程序进行改造娓娓展开。 作为国内校园服务场景最丰富的平台，笑联 App 已覆盖国内 130 所高校，服务近百万高校学生。 截止目前，笑联 App 内的 12 个业务模块目前已顺利实现小程序化。不仅获得媲美原生应用的用户体验，同时有效规避“发版周期长”、“无法快速在线修复 Bug”等弊端，实现真正的动态发布与更新能力。 点击观看mPaaS 小程序新品发布会 > > 项目背景 开篇先做个自我介绍，笑联 App 目前已是国内提供校园服务场景最丰富的平台，目前已覆盖 130 所高校，服务近百万高校学生。 因我们提供的服务类型囊括洗衣机、热水器、淋浴等多项功能，业务模块多元化，并且需满足每所学校在服务类型、标准方面的个性化设计，笑联 App 长期堆叠业务模块，缺乏规范的模块化设计，导致代码愈发臃肿，开发效率低下。 与此同时，随着业务的持续扩张，任一需求的迭代均需要重新发版审核，很显然如此繁琐的发版工期已无法满足高频更新的业务需要。 我们急需在技术侧找到对应的解决思路，一方面简化业务模块之间的耦合，加速日常的开发速度；另一方面架构上需实现模块化，找到动态发布与更新的解决方式。 我们针对市面上已开放的技术选型做了调研，Flutter 和 mPaaS 理论上都可以满足我们当时的选型要求，但 mPaaS 小程序动态更新的能力跟我们业务需求相吻合

作者 | 介龙平，英文名 leo，码农一枚 【Arthas 官方社区正在举行征文活动，参加即有奖品拿~ 点击投稿 】 1. 异常突起 HBase 集群的某一个 RegionServer 的 CPU 使用率突然飙升到百分之百，单独重启该 RegionServer 之后，CPU 的负载依旧会逐渐攀上顶峰。多次重启集群之后，CPU 满载的现象依然会复现，且会持续居高不下，慢慢地该 RegionServer 就会宕掉，慢慢地 HBase 集群就完犊子了。 2. 异常之上的现象 CDH 监控页面来看，除 CPU 之外的几乎所有核心指标都是正常的，磁盘和网络 IO 都很低，内存更是充足，压缩队列，刷新队列也是正常的。 普罗米修斯的监控也是类似这样的，就不贴图了。 监控指标里的数字，只能直观地告诉我们现象，不能告诉我们异常的起因。因此我们的第二反应是看日志。 （企业微信截图） 与此同时，日志中还有很多类似这样的干扰输出。 后来发现这样的输出只是一些无关紧要的信息，对分析问题没有任何帮助，甚至会干扰我们对问题的定位。 但是，日志中大量 scan responseTooSlow 的警告信息，似乎在告诉我们，HBase 的 Server 内部正在发生着大量耗时的 scan 操作，这也许就是 CPU 负载高的元凶。可是，由于各种因素的作用，我们当时的关注点并没有在这个上面，因为这样的信息

作者 | 长门 **导读：**本篇是《SpringCloud 应用在 Kubernetes 上的最佳实践》系列文章的第七篇，主要介绍了新功能上线时，如何尽快减少对线上用户的影响？发布系统需要提供回滚到前一个或前几个版本的能力，达到快速恢复线上业务的目的。 相关文章推荐： 《SpringCloud 应用在 Kubernetes 上的最佳实践 —— 开发篇》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(开发部署）》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 部署篇(工具部署)》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可灰度）》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 诊断（线上联调）》 《SpringCloud 应用在 Kubernetes 上的最佳实践 — 线上发布（可监控）》 前言 通常一次应用的线上发布就表示了一次新功能的上线。在上线过程中，可能发生一些非预期的情况，如新版本软件有 bug，或者功能不达预期，就会影响了线上客户的使用。为了尽快减少对线上用户的影响，发布系统需要提供回滚到前一个或前几个版本的能力。达到快速恢复线上业务的目的。 从应用的部署变更层次来看，可以分为以下三层： 所以对应了以下的回滚场景： 回滚应用内的配置

作者 | 李志鹏 近几年，随着 Go 语言社区逐渐发展和壮大，越来越多的公司开始尝试采用 Go 搭建微服务体系，也涌现了一批 Go 的微服务框架，如 go-micro、go-kit、Dubbo-go 等，跟微服务治理相关的组件也逐渐开始在 Go 生态发力，如 Sentinel、Hystrix 等都推出了 Go 语言版本，而作为微服务框架的核心引擎--注册中心，也是必不可缺少的组件，市面已经有多款注册中心支持 Go 语言，应该如何选择呢？我们可以对目前主流的支持 Go 语言的注册中心做个对比。 图 1 根据上表的对比我们可以从以下几个维度得出结论： 生态 ：各注册中心对 Go 语言都有支持，但是 Nacos、 Consul、Etcd 社区活跃，zookeeper 和 Eureka 社区活跃度较低； 易用性 ：Nacos、Eureka、Consul 都有现成的管控平台，Etcd、zookeeper 本身作为 kv 存储，没有相应的管控平台，Nacos 支持中文界面，比较符合国人使用习惯； 场景支持 ：CP 模型主要针对强一致场景，如金融类，AP 模型适用于高可用场景，Nacos 可以同时满足两种场景，Eureka 主要满足高可用场景，Consul、Zookeepr、Etcd 主要满足强一致场景，此外 Nacos 支持从其它注册中心同步数据，方便用户注册中心迁移； 功能完整性

导读 ：多年前，曾有媒体向丁水波提问：“对于你个人来说，转型过程中最痛苦的部分是什么？”“最关键的是市场意识的转变。耳听为虚眼见为实，做起来给外界看到了，他们才会明白和接受。很多东西得做完成功了，才可以让别人信服，但这中间的时间周期会比较长一点。”丁水波这样回应道。 近年来特步在运动鞋细分领域不断加码。2019 年，公司陆续收购了索康尼、迈乐、盖世威和帕拉丁的相关运营权，形成了涵盖大众运动、专业运动和时尚运动三大细分市场的品牌矩阵，打破了过去单一的品牌格局。但一系列收购也令特步的商誉增至 8.3 亿元。 与此同时，特步的旗下业务也在持续变革。 今年零售业受到受疫情巨大冲击的同时，也倒逼特步新营销业务的快速提升。疫情以来，数字化转型全面加速，品牌服装企业们纷纷奔向线上线下渠道融合变革的新零售模式。在这一重要趋势中，特步也不例外，今年特步电商业务通过调整内部货品结构、精准营销推广、布局直播业务等举措持续变革，强化新营销矩阵。相关数据显示，618 活动中，特步主品牌全渠道累计成交突破 2.5 亿元，国内品牌第三；特步儿童新品高速成长，全网增速达 77%。山海系列、猫和老鼠系列、騛速系列等受到消费者青睐。就这样，特步彻底破圈。而这一切的业务增长与都源于特步的第三次战略升级。 作为成立于 2001 年，中国领先的体育用品企业之一的特步，门店数 6230 家

**简介：** 对于大型的软件系统如互联网分布式应用或企业级软件，为何我们常常会陷入复杂度陷阱？如何识别复杂度增长的因素？在代码开发以及演进的过程中需要遵循哪些原则？本文将分享阿里研究员谷朴关于软件复杂度的思考：什么是复杂度、复杂度是如何产生的以及解决的思路。较长，同学们可收藏后再看。  作者 | 张瓅玶(谷朴) 阿里巴巴研究员 **导读：**对于大型的软件系统如互联网分布式应用或企业级软件，为何我们常常会陷入复杂度陷阱？如何识别复杂度增长的因素？在代码开发以及演进的过程中需要遵循哪些原则？本文将分享阿里研究员谷朴关于软件复杂度的思考：什么是复杂度、复杂度是如何产生的以及解决的思路。较长，同学们可收藏后再看。 > 软件设计和实现的本质是工程师相互通过“写作”来交流一些包含丰富细节的抽象概念并且不断迭代过程。> 另外，如果你的代码生存期一般不超过 6 个月，本文用处不大。 软件架构的核心挑战是快速增长的复杂性 ================== 越是大型系统，越需要简单性。 大型系统的本质问题是复杂性问题。互联网软件，是典型的大型系统，如下图所示，数百个甚至更多的微服务相互调用/依赖

作者 | 牛兔 导读 ：本文是《SpringCloud 应用在 Kubernetes 上的最佳实践》系列文章的第 11 篇，从前面两期开始我们进入到了高可用专题，分别介绍了流量防护和故障演练相关内容。本文将从另一个视角介绍如何保障业务高可用性：即业务准备阶段，提前进行线上的瓶颈定位和容量评估，以便更低成本、更高效/真实的发现系统瓶颈点，做到最精确的容量评估。 高可用体系介绍 首先来介绍下高可用体系，应用生命周期的高可用都有哪些策略、分别可以实现什么能力呢？ 从上图示意中可以看出，应用生命周期的整个过程中，都有相应的高可用策略，如前面 2 篇文章介绍的流量防护即为线上运行时的线上管控相关策略，混沌工程即为系统演练的相关策略，而全链路压测即为规划阶段的重要策略，其包括线上压测（即环境选择）、容量规划（即压测实施）、弹性伸缩（即生态内联动）。 以下将重点介绍容量评估的重要性，以及如何实施压测来实现容量评估。 为何要进行容量评估？ 关于容量评估的重要性及必要性已经是个老生常谈的问题了，分别从技术角度和业务战略角度总结如下： 容量评估的目的自然是解决容量问题，如新业务上线前的准备，大型营销活动的准备等等。大型活动中洪峰流量引起的系统表现不确定性，是最经典的适用场景。一个理想的营销活动周期应该是有如下闭环流程： 性能测试是容量评估的核心手段，性能测试之后通过客户端-应用系统

作者 | 张瓅玶(谷朴) 阿里巴巴研究员 **导读：**对于大型的软件系统如互联网分布式应用或企业级软件，为何我们常常会陷入复杂度陷阱？如何识别复杂度增长的因素？在代码开发以及演进的过程中需要遵循哪些原则？本文将分享阿里研究员谷朴关于软件复杂度的思考：什么是复杂度、复杂度是如何产生的以及解决的思路。较长，同学们可收藏后再看。 软件设计和实现的本质是工程师相互通过“写作”来交流一些包含丰富细节的抽象概念并且不断迭代过程。> 另外，如果你的代码生存期一般不超过 6 个月，本文用处不大。 软件架构的核心挑战是快速增长的复杂性 越是大型系统，越需要简单性。 大型系统的本质问题是复杂性问题。互联网软件，是典型的大型系统，如下图所示，数百个甚至更多的微服务相互调用/依赖，组成一个组件数量大、行为复杂、时刻在变动（发布、配置变更）当中的动态的、复杂的系统。而且，软件工程师们常常自嘲，“when things work, nobody knows why”。 图源： https://divante.com/blog/10-companies-that-implemented-the-microservice-architecture-and-paved-the-way-for-others/ 如果我们只是写一段独立代码，不和其他系统交互，往往设计上要求不会很高，代码是否易于使用、易于理解