ucc

事务的概念在 这篇文章 中描述过，在分布式系统中，读写位于多个节点的数据，如果依旧想保证ACID特性，就必须实现分布式事务。而其实现关键则是适当的提交协议，目前最简洁，且使用最广泛的无疑是两阶段提交协议（2PC）。 1.实现分布式事务关键组件 单机系统通过 事务管理器（transaction manager，TM） 实现本地事务。分布式系统中，需要协调多个节点的事务管理器，共同提交成功或失败，因此需要 事务协调者（transaction coordinator，TC） 。一个分布式事务管理器，可以粗略地划分为这两个子系统。这两个子系统根据自己在事务执行中扮演的角色，也可称之为 参与者 与 协调者 。 本地事务管理器负责本机事务并发控制和异常恢复等功能，事务协调者负责开启事务，将事务划分为多个子事务分发到相应的节点执行，并协调事务完成（一起提交成功或失败）。在实现中，TM和TC可以实现在同一个进程中，也可以部署在不同的节点。 2.经典两阶段提交协议 两阶段提交的流程比较简单。当分布式事务T执行完成，即事务执行的各节点都告知协调者TC，事务已经执行完成，TC便开启两阶段提交流程。 Phase 1 Prepare： 1.TC写本地日志，并持久化。TC向所有参与者发送Prepare T消息。 2.各参与者TM收到Prepare T消息，根据自身情况，决定是否提交事务。 如果决定提交

作者 | 悟鹏 阿里巴巴技术专家 **导读：**本文尝试以日常开发流程为起点，分析开发者在每个阶段要面对的问题，然后组合解决方案，提炼面向 Serverless 的开发模型，并与业界提出的 Serverless 产品形态做对应，为开发者采用 Serverless 架构和服务提供参考。 近两年来，Serverless 概念在开发者中交流的越来越多，主题分享呈现爆发趋势，如在云原生领域颇具影响力 KubeCon&CloudNativeCon 会议中，关于 Serverless 的主题，2018 年有 20 个，到 2019 年增长至 35 个。 在 Serverless 产品层面，从最早的 AWS Lambda，到 Azure Functions、Goolge Functions、Google CloudRun，再到国内阿里云 Serverless Kubernetes、Serverless 应用引擎、函数计算等，面向计算的 Serverless 云上基础设施越来越丰富。 新概念、新产品的产生不是凭空出现，它们诞生之初要解决的是当前问题。随着实践者对问题域的理解越来越清晰和深刻，问题的处理方法也会逐步迭代，更接近问题本质的解决方案也会出现。若不从问题域出发来理解解决方案，容易陷入两个极端，即「它能解决一切问题」和「它太超前了，理解不了」。 从日常迭代看 Serverless 图 1

**Alibaba Cloud Native Day 第二期将于 5 月 30 日全天进行线上直播！**届时，上海越光医疗科技 CTO、原编程之夏学员现 Alibaba Nacos PMC 及五位阿里技术专家齐聚，带来不一样的技术实践视角！通过本场活动，您将了解到： 真实的行业实践：ECI+K8s 在医疗行业的落地； 一线的演进视野：云原生时代消息中间件的演进路线，以及云原生软件供应链安全演进； 第一视角的实操演示：1. 聚焦 Nacos 内核构建；2. 基于 OAM 构建大规模可扩展 PaaS 平台实践；3. Spring Cloud Alibaba 的手把手沙箱试用；4. Serverless 在大规模数据处理的实践。 时间 ：5 月 30 日 10:00 - 16:50 地点 ：线上直播 ** 报名方式**： https://yqh.aliyun.com/live/CloudNative （点击链接，立即预约直播） 【详细信息看这里】 来源： oschina 链接： https://my.oschina.net/u/3874284/blog/4287031

作者 | 阿里云原生 在 6 月 9 日 2020 阿里云线上峰会上，阿里云智能基础产品事业部高级研究员蒋江伟重磅发布了云原生裸金属方案。 新一代容器服务 ACK，可以将最新神龙弹性裸金属实例的强大性能发挥得淋漓尽致，具备 极致性能、高效调度、全面安全 的特点： 新一代神龙架构具备业界第一的 I/O 转发能力，提供最高 100G 网络带宽；阿里云高速 Terway 容器网络通过网卡直通和数据平面加速， 延迟下降 30% ； 第 7 代实例最大支持 192 个 vCPU。ACK 智能 CPU 调度可以轻松释放强大算力，无需应用调整可以实现 QPS 20~30% 提升；结合 ENI 网卡密度提升， 可以缩减 50% 的计算成本 ； 弹性裸金属实例支持阿里云安全容器，提升端到端安全隔离能力，与开源方案相比 性能提升 30% ，也支持阿里云 首发机密计算容器 ，基于软硬一体技术有效保护数据隐私。 在阿里巴巴内部，神龙架构已大规模应用于淘宝、天猫、菜鸟等业务，解决了高峰值下的业务性能和稳定性问题。在外部，尤其是在这次疫情影响下，很多企业面临快速扩容的压力，如在线教育行业，通过阿里云容器+神龙方案，企业可以从容应对流量突增的难题。 视源股份（CVTE）的希沃系列教育平稳应对疫情期间指数级增长的课堂流量，视源电子运维负责人许坤丰称，“疫情之下，希沃课堂作为教育信息化应用和服务工具提供商

作者 | 许晓斌 阿里云高级技术专家 本文整理自《Serverless 技术公开课》第 1 讲， 点击开始学习 。 关注 “ Serverless ” 公众号，回复 入门 ，即可获取 Serverless 系列文章 PPT。 传统单体应用架构 十多年前主流的应用架构都是单体应用，部署形式就是一台服务器加一个数据库，在这种架构下，运维人员会小心翼翼地维护这台服务器，以保证服务的可用性。 （单体架构） 随着业务的增长，这种最简单的单体应用架构很快就面临两个问题。首先，这里只有一台服务器，如果这台服务器出现故障，例如硬件损坏，那么整个服务就会不可用；其次，业务量变大之后，一台服务器的资源很快会无法承载所有流量。 解决这两个问题最直接的方法就是在流量入口加一个负载均衡器，使单体应用同时部署到多台服务器上，这样服务器的单点问题就解决了，与此同时，这个单体应用也具备了水平伸缩的能力。 （单体架构-水平伸缩） 微服务架构 1. 微服务架构演进出通用服务 随着业务的进一步增长，更多的研发人员加入到团队中，共同在单体应用上开发特性。由于单体应用内的代码没有明确的物理边界，大家很快就会遇到各种冲突，需要人工协调，以及大量的 conflict merge 操作，研发效率直线下降。 因此大家开始把单体应用拆分成一个个可以独立开发、独立测试、独立部署的微服务应用，服务和服务之间通过 API 通讯，如

作者 | 承风 阿里巴巴高级前端技术专家 **导读：**建立结构化的思维，以结构化的模式驱动工作，以结构化的体系构建自身的能力，小到写 PPT、大到为业务提供更大价值，都是非常值得我们使用的模式。阿里巴巴数字供应链事业部高级前端技术专家 - 承风，将会在本文中和大家分享他在建立和践行结构化思维过程中的方法论。 引言 在每年自评、汇报、工作中总会感受到一些结构化带来的问题： 老板问我当前做的事情怎么样了，我讲了合作中的难点、视觉风格问题、业务情况、代码质量······工作的进展，说了半小时，老板还是 get 不到我做的事情的情况和价值，是老板不在意这件事、还是我语言表达能力不行？ 我这一年做了很多事情，都有一定产出，但是跳出细节来看，发现对业务、对团队价值都不大，是我做得不好、还是运气不好做的事情不好？ 最近流行 codeless，我打算研究下可视化搭建；团队业务涉及到流程编排，我打算研究下 TMF······一年下来折腾了不少成果出来，似乎老板也没有很认可，是我不讨老板喜欢还是做的事情没价值？ 这些问题，根据我自己工作经验的总结，认为大都是对结构化认知不足和践行不佳导致的。 第一个问题：对事情的认知和表述结构化方面存在问题 - 结构化的思维相关问题； 第二个问题：做事儿多而杂不成体系 - 结构化的工作模式问题； 第三个问题：学习和成长缺乏重点 - 结构化的能力建设的问题。

作者 | 声东 阿里云售后技术专家 **<关注阿里巴巴云原生公众号，回复 排查 即可下载电子书> ** 《深入浅出 Kubernetes》一书共汇集 12 篇技术文章，帮助你一次搞懂 6 个核心原理，吃透基础理论，一次学会 6 个典型问题的华丽操作！ Istio is the future！基本上，我相信对云原生技术趋势有些微判断的同学，都会有这个觉悟。其背后的逻辑其实是比较简单的：当容器集群，特别是 Kubernetes 成为事实上的标准之后，应用必然会不断的复杂化，服务治理肯定会成为强需求。 **Istio 的现状是，聊的人很多，用的人其实很少。**所以导致我们能看到的文章，讲道理的很多，讲实际踩坑经验的极少。阿里云售后团队作为一线踩坑团队，分享问题排查经验，我们责无旁贷。这篇文章，我就跟大家聊一个简单 Istio 问题的排查过程，权当抛砖。 二分之一活的微服务 问题是这样的，用户在自己的测试集群里安装了 Istio，并依照官方文档部署 bookinfo 应用来上手 Istio。部署之后，用户执行 kubectl get pods 命令，发现所有的 Pod 都只有二分之一个容器是 READY 的。 # kubectl get pods NAME READY STATUS RESTARTS AGE details-v1-68868454f5-94hzd 1/2 Running 0

作者 | Cloud Toolkit 近年来，容器技术以迅雷不及掩耳之势迅速蔓延开来，容器技术基于各种场景的尝试与实践更是层出不穷，它的崛起改变了我们创建、发布与运行应用的方式，实现了资源的独立与隔离、相较于传统的虚拟化技术，它更加轻量化。 随着以 Docker 为代表的容器技术在越来越多的业务场景中被应用，越来越多开发者开始习惯将应用打包成标准格式镜像并存放在镜像仓库中以便完成日常部署发布、团队协作等工作。但在真正的生产环境中，我们会产生大量镜像，不管是第三方还是自建，而这些镜像伴随而来的是部署、保存、分发使用等大量繁琐、重复的部署、管控工作。 对于开发者而言，在本地 IDE、镜像仓库、容器等多个产品间来回切换，不仅耗费大量工时与精力，而且繁琐细碎的操作更容易造成一系列失误。 说到底，哪个开发者想做一个天天机械性重复工作的工具人呢？谁不想做点有创造性的工作呢？ 面对这样的难题，Cloud Toolkit 给出了答案～ 在 IntelliJ IDEA 安装和配置 Cloud Toolkit 后，只需在配置界面设置部署参数即可实现自动化部署，将应用快速部署到镜像仓库，并借助阿里云提供安全的镜像托管能力，高效管理镜像 。 那么，我们来看看到底如何做，才能实现部署提速 8 倍？首先，先和大家聊一聊搭配免费 IDE 插件即可实现一键部署、持续集成与交付的的容器镜像仓库 ACR。

作者：田杰 在数据库的日常使用中，来自应用的高并发场景并不罕见，其标志性的表现为 高新连接创建速率（CPS，比如 PHP 短连接）、发送大量请求到 DB 数据库层。 如同 海啸 ，大量的新建连接和请求猛烈的冲击考验着 DB 层的处理能力，非常容易出现数据库被冲击 hang 住或响应极其缓慢的情况（想象下无预知无缓冲的短时间内突然工作量翻涨数倍，会不会立时被忙哭了 ^_^）。 而数据库通常作为架构最下端的数据存取汇聚单元，其性能表现和稳定性往往决定了应用的最终表现和使用体验，可谓业务生死之大事，不可不察。 由此，我们一起看一下 “海啸” 场景下可以用来 “保命” 的各种解决方案。 注： • 本文目标是总结高并发场景下的应对处理方法，而应对热点更新（秒杀）场景的“招数”会另文介绍。 • 本文的主旨在于方便数据库的使用者理解业务高并发请求场景下的保障 DB 可用性和稳定性的机制和方法，非机制的全面深度技术细节介绍。 1. 线程池 1.1 模型 我们举一个生活中的例子方便大家理解 线程池（Thread Pool）。 比如有个银行，有 10 个窗口（ 实例规格 CPU 数量 )，官方说可以容纳 10 人 （Client Thread） 。平时呢，人也不多，一直顺畅。稍微忙一点呢，大家挤挤。这个 10 人的地方，挤个 50 人也可以（不是每个人时刻都在窗口办业务）。效率也挺高。 年底发工资

4月27日CDN云课堂中，阿里云智能技术专家洪晓龙在线分享《阿里云CDN轻量编程环境》，对EdgeRoutine的背景、功能、案例实践介绍并在线进行上手操作演示，希望更多用户能够使用CDN轻量编程环境服务自主编程、快速落地实际线上业务。本文为直播分享全文。 云原生与边缘计算概念火热 以云原生为理念的基础服务快速增长 近年来，“云原生”概念在技术领域大热，企业上云意愿越来越强烈。不管在国内还是全球，云原生技术在公共云和私有云的使用量一路领先增长，Gartner等多家行业机构已经预测云原生即将进入爆发阶段。 而同属云原生阵营， Serverless&FaaS年增长率这一点上已经逐渐赶上甚至超过以容器形态提供服务的使用量。Serverless&FaaS已经证明了其拥有巨大的技术优势和商业价值潜力。 5G引爆边缘计算的概念 除了“云原生”，“边缘计算”也是近年来最热门的技术领域之一。CDN其实就是边缘生态的重要一环，在CDN遍布全球的边缘节点上提供计算服务是目前“边缘计算”概念快速落地的最大助力。边缘计算的最大特性低时延，Gartner甚至预测到2025年，超过75%的云服务将外迁到边缘。目前，边缘计算的应用场景已经陆续覆盖到交通、医疗、娱乐等各行业各领域，离大众生活越来越近。 云原生和边缘计算的组合碰撞能够催生出什么样的技术和产品？ 传统的IaaS是抽象物理机资源来提供服务