时区：Asia/Shanghai · 窗口：约过去 24–36 小时（含仍在发酵的 9/10 晚间官方帖）
约 10 条高信号讨论；指标来自抓取时公开 metrics，未编造。

今日要点

1. Cursor Projects 正式上线：持久协调 Agent + 并行 Subagents，讨论量断层领先。
   
2. Devin Fusion / SWE-2 发布后，Artificial Analysis 首次把多模型 harness 放进 Coding Agent Index。
   
3. Anthropic 发布迄今最详 Threat Intelligence Report，Claude Code 被点名出现在真实滥用链中。
   
4. DeepSeek-V4.1-Flash 余热仍在；技术报告用多 harness 证明模型不绑定单一 scaffold。
   
5. 国内侧：Qoder 上线 Kimi K2.8 Preview；Trae / CodeBuddy 本窗 X 上几乎无官方硬新闻。

1. Cursor 发布 Projects：协调 Agent 成为控制面

要点：官方介绍 Projects——不再为每个任务开新 chat，而是在单一持久线程里与 coordinator agent 协作；可主动调度 subagents，并随时间积累项目知识（类比 @bot 的 always-on）。

为何值得看：本窗互动最高的产品帖之一（抓取时约 1.05 万赞 / 222 万展示 / 近 5k bookmark）。社区解读普遍指向「IDE → 控制面 / 组织层」迁移，而不只是更快补全。

• 作者：@cursor_ai
  
• 链接：https://x.com/cursor_ai/status/2098162488013455784
  

2. 中文圈拆解：Projects = 长期存在的编码团队

要点：@frxiaobei 指出 Projects 把研究 / 拆解 / 开发 / 测试交给共享上下文的 Subagents；可不依赖本机常开，并可盯 PR、CI、Slack；文中称主要使用 Projects 的工程师合并 PR 约为原来的 6 倍（转述 Cursor 博客口径，非独立验证）。

为何值得看：把官方英文叙事翻译成可执行产品直觉，并明确对标 Codex / Claude Code「人守在电脑前派活」的过渡形态。

• 作者：@frxiaobei
  
• 链接：https://x.com/frxiaobei/status/2098368627368222861
  
• 相关：https://cursor.com/cn/blog/projects
  

3. Artificial Analysis：Devin Fusion 首次进入 Coding Agent Index

要点：@ArtificialAnlys 独立评测 Devin Fusion（frontier lead + 便宜 sidekick）。Fable 5.1 (xhigh) + SWE-2 (medium) 约 62 分；Astra (xhigh) + SWE-2 约 59 分但更便宜、更快。称首次把 multi-model coding agent 纳入 Index，并接近保留 frontier 表现同时降本。

为何值得看：抓取时约 998 赞 / 88 万+ 展示，是本窗 Devin 线最硬的第三方背书；把「Fusion / harness」从营销话术落到可比较的 cost–quality 曲线。

• 作者：@ArtificialAnlys
  
• 链接：https://x.com/ArtificialAnlys/status/2098504936984293447
  

4. Cognition：SWE-2 + Devin Voice

要点：@cognition 发布 SWE-2（称在多项 leading evals 接近 frontier，成本最高可低约 70%）；同日推出 Devin Voice（语音下指令，powered by GPT-Live + SWE-2）。

为何值得看：与 Fusion 评测同属同一发布波次；Voice 把「agent 入口」从 IDE/CLI 推到电话/语音交互。

• SWE-2：https://x.com/cognition/status/2098069235733823965 · @cognition
  
• Devin Voice：https://x.com/cognition/status/2098142686486356185 · @cognition
  

5. Anthropic Threat Intelligence：Claude / Claude Code 真实滥用案例

要点：@AnthropicAI 发布迄今最详 threat intelligence report，覆盖网络攻击、影响操作、监控、生物与武器相关误用，并称已 disrupt 报告中全部行动。二级传播帖（如 @DailyDarkWeb、@ns123abc）强调 Claude Code 被用于端到端作战流程（侦察→利用→横向→勒索等）。

为何值得看：官方帖互动极大（抓取时数万赞、数千万展示）；对做 coding agent / MCP 安全与滥用检测的人是必读一手材料。报告：https://www.anthropic.com/threat-intelligence-report-september-2026

• 作者：@AnthropicAI
  
• 链接：https://x.com/AnthropicAI/status/2098097512544444447
  
• 传播摘录：https://x.com/ns123abc/status/2098144432570630380
  

6. DeepSeek-V4.1-Flash：模型热 + Harness 解耦实验

要点：@deepseek_ai 发布 DeepSeek-V4.1-Flash（新架构家族最小模型，原生视觉）。@shao__meng 解读技术报告 5.3.4：在 Claude Code / Codex / OpenCode / Pi / mini-SWE / DSH 等 scaffold 上对比 DeepSWE 与 Terminal-Bench，强调模型不依赖单一 Agent Harness；mini-SWE 在部分榜上甚至高于更重 harness。

为何值得看：一边是模型发布余热，一边是「选 Agent 不能只看模型榜」的实践结论，和本窗 Fusion / Projects 叙事互相印证。

• 官方：https://x.com/deepseek_ai/status/2097930608790167907 · @deepseek_ai
  
• 解读：https://x.com/shao__meng/status/2098615707953254567 · @shao__meng
  

7. 开源栈刷屏：OpenCode / Superpowers / gstack 等 10 仓

要点：@RodmanAi（及高曝光转述 @RoundtableSpace）列出 10 个强化 Claude Code / Codex / Cursor / OpenCode 的开源仓：gstack、context-mode、OpenCode、Superpowers、learn-claude-code、ruflo、opencode-agents、agent-skills、paseo、MCP servers。@bkdgiffug 另推 Superpowers 方法论（TDD + worktree + 多 agent review）。

为何值得看：本窗「工具推荐」类最高互动内容之一；反映生态重心从「换一个 IDE」转向「给 agent 装 skills / 流程 / 编排」。

• 作者：@RodmanAi
  
• 链接：https://x.com/RodmanAi/status/2098340192499413240
  
• 转述：https://x.com/RoundtableSpace/status/2098392364033130983
  
• Superpowers 中文：https://x.com/bkdgiffug/status/2098277103766851721
  

8. Unity × Claude Code：官方一键插件（29 skills）

要点：@RoundtableSpace 称 Unity 推出 Claude Code 官方一方插件：29 个 native Unity skills，支持 CLI 工作流与 Editor 直控，目录内一键安装、无需配置。

为何值得看：垂直行业（游戏引擎）把 coding agent 嵌进生产工具链的信号；若属实，是 Claude Code 插件生态的重要一等公民用例。

• 作者：@RoundtableSpace
  
• 链接：https://x.com/RoundtableSpace/status/2098588656554381796
  

9. Qoder 上线 Kimi K2.8 Preview（国内产品）

要点：官方 @qoder_ai_ide 宣布 Kimi K2.8 Preview 已在 Qoder 可用，称总体接近 Kimi K3、编码与 agent 能力更强，推理效率优于 K2.7 Code。另有 @phodal 分享 Qoder Canvas Mobile Use 插件（真机标注 → Agent 改码）。

为何值得看：本窗国内产品里少有的官方可核验动态；模型接入节奏快。Trae / CodeBuddy 同窗在 X 上几乎无高互动官方发布。

• 作者：@qoder_ai_ide
  
• 链接：https://x.com/qoder_ai_ide/status/2098618998711881914
  
• 相关：https://x.com/phodal/status/2098387538537046122
  

10. Google × Mechanize 人才交易 & Antigravity 语境

要点：@wallstengine 报道 Google 完成与 Mechanize 的人才交易（谈及规模超 $1.5B 量级，最终条款未披露），多人加入 DeepMind midtraining；Mechanize 侧重提升模型 coding。文中回顾此前 Windsurf 人才交易，前 CEO Varun Mohan 现主导 Google agentic coding 项目 Antigravity。

为何值得看：不是直接产品 changelog，但是「评测 / coding 能力人才」稀缺与 Antigravity 布局的背景噪音。

• 作者：@wallstengine
  
• 链接：https://x.com/wallstengine/status/2098489441174327790
  

2002 jira

manage bugs, plan features, and track tasks version-history, file attachments, and a search function for issues

Because of Jira’s comprehensiveness and complexity, the product came with a steep learning curve

2004 conflunce

Jira was bringing in revenue provide simple wiki functions: enterprise knowledge management systems

Confluence also integrated really well with Jira

Cannon-Brookes said: “We had two rocket engines driving us along, not just one

2005 profitable without having taken any venture capital (3 years after founding)

no sales people 30-day free trial

2007 buy developer tools—Fisheye, Crucible, and Clover

https://www.infoq.com/news/2007/08/atlassiancenqua/ They integrated these products into their offerings by allowing the services to continue uninterrupted, but moved all of the products’ information and documentation over to the Atlassian site

The freemium sales and distribution model, as well as the early acquisitions, created many revenue streams that lead to over $50M in ARR by 2010. At this point the company was eight years old and had already been profitable for five years.

2010-2015: Integrating acquisitions and spreading to other teams

become exceptional at acquisition and folding useful pre-existing products into the Atlassian suite. acquire the right products, integrate them well, and continue expanding their user base to users that were tangential to dev teams.

2010 Atlassian raised $60 million in secondary funding

Atlassian raised $60 million in secondary funding At this point, Atlassian had over 20,000 customers worldwide acquire Bitbucket, a hosted service for code collaboration

2012 acquired the hosted private chat service Hipchat

Hipchat is “perfect for product teams but fantastic for any team.”

2013 service desk

released a service desk offering on top of Jira that targeted the IT market new features included a customer-centered interface, an SLA engine, customizable team queues, and real-time reports and analytics. over $100 million a year.

2015 Atlassian’s Git services were fast growing

Bitbucket’s customer growth the year before was around 80%, and that 1 in 3 Fortune 500 companies used Bitbucket. https://techcrunch.com/2015/09/22/atlassian-updates-its-git-services-combines-them-under-the-bitbucket-brand/

Combining two separate companies can be a nightmare, with clashing brands, personalities, and even code bases. Atlassian not only developed the skill of making smart acquisitions—they’ve also mastered the treacherous integration process from people to code.

2015-Present: Expanding to competitive and lucrative markets

company still needs to find a way to stay relevant to small teams Many of their moneymaking products are getting unnecessarily complex for small teams

2015: Atlassian held its IPO in December and started trading shares with a market cap of nearly $5.8 billion.

invested over 40% of their revenue into R&D wanted to keep up their 30% YoY growth

2016 more ubiquitous tool provider and help companies maintain their software, Atlassian acquired Statuspage

2017 target smaller teams by acquiring the lightweight project management tool Trello. pivoting Hipchat’s services into Stride.

Trello is a much simpler project management tool than Jira, and the simple Kanban board covers much broader use cases Stride. Atlassian made another huge product move by pivoting Hipchat’s services into an Atlassian-branded product called Stride. It’s a Slack competitor for team-wide messaging

参考

attlassian 发展历史： https://nira.com/atlassian-history/ https://tomtunguz.com/atlassian-s-1/

作者：萨提亚.纳德拉，微软第三任 CEO，印度裔美国人。

萨提亚刚上任时，微软正经历着阵痛：在全球的移动化浪潮中，微软逐步掉队，无论是Windows phone，还是鲍尔默任上收购的芬兰手机巨头诺基亚，除了伤害了与合作伙伴，比如Samsung的关系之外，几乎没有激起任何水花。微软的股价也在这阵痛期持续下行。

本书的书名很有意思，一语双关。Hit refresh 既是我们使用Windows操作系统时非常常用的操作（记得我当时使用的是Windows xp、Windows 7，系统经常陷于卡顿，用户通常都会在百无聊赖之际，不停地右键 -> 刷新）；也是指我们在面对当今日新月异的社会，个人和公司都需要持续地自我刷新，否则很容易被淘汰出局，没有未来。

摘要和感悟

一、书中反复强调的两个关键品质： 1. 同理心。

同理心是一种识别和理解他人、动物甚至虚构人物的想法或感受的能力。这是一种试图认同他人的处境、观点或经历的尝试。同理心是指从别人的角度来看待事物，而不是从自己的角度，想象自己在他们的位置上。 感兴趣的同学可以搜一下同理心和同情心的区别（同理心英文 Empathy，同情心英文 Sympathy），可能会加深对这个词的理解。

在阿里经常提到的HR需要具备的素质：共情，其实就是相同的意思。

1. 成长型思维。 书中提到两种思维模式：成长型思维模式（growth mindset）和固化型思维模式（fixed mindset）。从名字看应该很容易分出好坏🙃🙃。 拥有成长型思维模式的领导者，他们往往更具包容性。对他们而言，带领团队不是为了凸显自己的优越，而是为了促进自己、队员和整个团队的成长。 但是要持续不断地做到这一点，谈何容易。

看到一句话，有点扎心🤣🤣：

成长型思维模式是违反人性的，这也就是为什么我们大多数人一辈子如此平庸。 一个人无法去准确地预测未来科技变化，但是成长型思维模式可以使他更好地对不确定性做出反应，并且在技术快速变化的情况下，去纠正自己所犯的错误。

另外，本书中纳德拉面对困难时的心态让人印象深刻。他的儿子一出生就患有先天性脑部麻痹，一生下来就住进了 ICU 儿童重症监护室，此后长期每天接受各种治疗。也是他的儿子，让他真正感受到同理心的重要性；在他儿子治疗过程中，科技发挥的作用，也让他深刻体会到科技超过了生意，科技向善。

二、萨提亚上任后，微软几个显著的变化： 1. 提出“移动为先，云为先” 的战略。 从“设备与服务提供商” 转型为“移动为先，云为先”。“云为先”方面，微软做的非常出色，Azure已经成为事实上的全球第二大云厂商。但是“移动为先”的落地效果确实一般。

1. 与长期竞争对手的对抗转为合作、共赢。

下面一段是书中纳德拉描述微软与苹果合作时的情境：

今天，我的首要任务就是满足我们的数十亿客户的需求，而无论他们选择何种手机或平台。唯有如此，我们才能持续成长。为此，我们有时候会和长期对手握手言和，追求出人意料的伙伴关系，重振长期关系。这些年来，我们更专注于客户需求，因而也就学会了共存与竞争。

对于和竞争对手建立伙伴关系，微软产品线上的一些领导者起初感到担忧。这种抗拒心理的背后逻辑是博弈论，即用数学模型来解释合作与冲突。建立伙伴关系经常被视为零和博弈，即一方所得为另一方之所失。但我不这么看。如果做得好，伙伴关系会把蛋糕做大，人人都会受益。是的，客户会受益，伙伴关系中的任何一方也都会受益。我们最终达成的共识是，与苹果的这一伙伴关系将有助于把Office产品的价值传递给每一个人，而苹果也承诺通过其iOS平台展示Office的强大功能，这将进一步强化微软作为苹果顶级开发者的地位。

三、作为技术和工程背景出身的高管，萨提亚对技术的熟悉的广度和与业务的结合程度，确实让人折服。本书萨提亚着重讲了三个微软比较看重和布局的技术： * 混合现实（mixed reality） * 人工智能（AI） * 量子计算（quantum computing）

本书是纳德拉17年写的，但是这三项技术，目前来看仍然非常重要，并处于高速发展阶段。比如混合现实，现在有个类似但是更火的概念 -- 元宇宙，来描述；人工智能的发展则依然如火如荼，应用在社会生活的方方面面；量子计算则在4年后的今天，依然没有取得突破性的进展（目前基本都处在通过不同技术路径，不断实现对更多量子比特的操纵这个阶段），不过一旦取得进展，对当今的信息技术发展将是颠覆性的（微软在量子计算领域目前来看是走了弯路，已经落后于其他竞争对手）。

其他

可能有人觉得，为什么印度人可以在美国top级的科技公司做到最高位置，中国人怎么就没有做到的呢？ 纳德拉并不是普通印度人。个人能力、品质固然重要（这个决定上限），但是没有家庭背景作为跳板（这个决定下限，但是很多人一出生他的下限就超过其他人努力一辈子所能达到的上限），大多数情况根本连机会都没有。纳德拉的爸爸，是印度政府官员，年纪轻轻就执掌有着上百万居民的印度行政区（供参考：去世时，印度副总统发推致哀的那种），妈妈是大学梵语老师。书中谈到了纳德拉在青年时代，并不是太上进，他的父亲如何引导和帮助他的。

在企业数字化转型的今天，越来越多的业务演变成数字化业务，数字化对于业务渠道、竞争格局、用户体验、降本增效等诸多方面都带来更加严苛的要求。基于云原生架构，可以充分利用云计算优势，释放云计算的技术红利，让业务更敏捷、成本更低的同时，具备更灵活的又可伸缩性。

2. 云原生架构的定义

从技术的角度，云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在将云应用中的 非业务代码部分进行最大化的剥离，从而让云设施接管应用中原有的大量非功能特性（如弹性、韧性、安全、 可观测性、灰度等），使业务不再有非功能性业务中断困扰的同时，具备轻量、敏捷、高度自动化的特点。

由此带来的几个大的变革：

• 代码结构发生巨大变化。云把三方软硬件能力升级为服务，大大降低开发和运维人员的工作复杂度。

• 非功能性特性的大量委托。大量分布式场景下复杂的非功能特性，由云产品处理掉。

• 高度自动化的软件交付。基于容器、面向终态的标准化的软件交付。

云原生架构的几大原则：

• 服务化原则

• 弹性原则

• 可观测原则（在云这样的分布式系统中， 让一次 APP 点击背后的多次服务调用的耗时、返回值和参数都清晰可见，甚至可以下钻到每次三方软件调用、SQL 请求、节点拓扑、网络响应等）

• 韧性原则（从多个维度诠释了软件持续提供业务服务的能力，提升软件的 MTBF（Mean Time Between Failure，平均无故障时间））

• 所有过程自动化原则

• 零信任原则

• 架构持续演进原则

云原生架构的几大主要架构模式：

• 服务化架构模式

• Mesh 化架构模式（将中间件框架从业务进程中剥离，进一步与业务代码解耦）

• Serverless 模式（Serverless 非常适合于事件驱动的数据计算任务、计算时间短的请 求 / 响应应用、没有复杂相互调用的长周期任务）

• 存储计算分离模式

• 分布式事务模式

• 可观测架构（包括 Logging、Tracing、Metrics 三个方面）

• 事件驱动架构

3. 主要云原生技术

3.1 容器技术

容器作为标准化软件单元，它将应用及其所有依赖项打包，使应用不再受环境限制，在不同计算环境 间快速、可靠地运行。容器技术让开发所需要的灵活性、开放性和运维所关注的标准化、自动化达成相对平衡。

容器技术的三个核心价值：

• 敏捷（基于容器技术，可以大大提升软件交付的效率）

• 弹性（快速的扩缩容）

• 可移植性（容器：应用分发和交付的标准技术；Kubernetes：资源调度 和编排的标准，屏蔽了底层架构差异性，帮助应用平滑运行在不同基础设施上）

容器编排

容器编排的事实标准：Kubernetes。Kubernetes 提供了分布式应用管理的核心能力：

• 资源调度

• 应用部署与管理

• 自动修复

• 服务发现与负载均衡

• 弹性伸缩

Kubernetes 在容器编排中有几个关键设计理念：声明式 API、可扩展性架构、可移植性。

3.2 云原生微服务

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微 服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。

在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、 可用性与安全性。

微服务设计的约束：

• 微服务个体约束（微服务应用，所完成的功能在业务域划分上应是相互独立的。满足SOLID 原则中单一职责原则（SRP, Single Responsibility Principle））

• 微服务与微服务之间的横向关系（服务的发布、订阅，服务之间的调用，在高性能场景下的考虑，限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配）

• 微服务与数据层之间的纵向约束（提倡数据存储隔离（DSS, Data Storage Segregation）原则，取读写分离（CQRS）手段，计算与存储分离原则）

• 全局视角下的微服务分布式约束（高效运维整个系统，全自动化的 CI/CD 流水线满；全链路、实时和多维度的可观测能力成为标配）

云原生微服务典型架构：

• 第一代。单服务负责从上往下的所有逻辑（业务逻辑、上下游寻址、通讯，以及容错等）

• 第二代。服务之间的通讯以 及容错机制开始模块化，形成独立服务框架。

• 第三代。服务网格，原来被模块化到服务框架里的微服务基础能力，被进一步的从一 个 SDK 演进成为一个独立进程 - Sidecar。

• 第四代。Serverless。微服务进一步由一个应用简化为微逻辑（Micrologic），更多可复用的分布式能力从应用中剥离。

主要微服务技术：Apache Dubbo 、Spring Cloud、Eclipse MicroProfile、Tars（腾讯将其内部使用的微服务框架 TAF（Total Application Framework））、SOFAStack（Scalable Open Financial Architecture Stack）、Dapr（Distributed Application Runtime）。

3.3 Serverless

Serverless服务的几大特征：

• 全托管的计算服务

• 通用性

• 自动的弹性伸缩

• 按量计费

函数计算（Function as a Service）是 Serverless 中最具代表性的产品形态。下面是传统的弹性计算服务、基于容器的 Serverless 应用服务和函数计算的对比：

Serverless的几个主要场景：

• 小程序 /Web/Mobile/API 后端服务

• 大规模批处理任务

• 基于事件驱动架构的在线应用和离线数据处理

• 开发运维自动化

Serverless模式的几个技术关注点：

• 计算资源弹性调度

• 负载均衡和流控

• 安全性

3.4 开放应用模型（OAM）

2019 年末，阿里云联合微软共同发布了 Open Application Model (OAM) 开源项目，其主要目标是解决从 Kubernetes 项目到“以应用为中心”的平台之间最关键环节 —— 标准化应用定义。（这是阿里主动制定行业规范的一个非常棒的开始。）

通过OAM，建立对应用和它所需的运维能力定义与描述的标准规范。OAM 的描述模型是基于 Kubernetes API 的资源模型（Kubernetes Resource Model） 来构建的，它强调一个现代应用是多个资源的集合，而非一个简单工作负载。

OAM的核心概念：

• 组件依赖（Component）。OAM 定义和规范了组成应用的组件。例如，一个前端 Web Server 容器、数据库服务、后端服务容器等。

• 应用运维特征（Trait）。OAM 定义和规范了应用所需的运维特征的集合。例如，弹性伸缩和 Ingress 等运维能力。

• 应用配置（Application Configuration）。OAM 定义和规范了应用实例化所需的配置机制，从而能够将上述这些描述转化为具体应用实例。运维人员可以定义和使用应用配置来组合上述的组件和相应的特征，以构建可部署的应用交付实例。

一个基于 OAM 构建的 Kubernetes 应用管理平台示意图：

3.5 Service Mesh 技术

Service Mesh 是分布式应用在微服务软件架构之上发展起来的新技术，旨在将那些微服务间的连接、安全、流量控制和可观测等通用功能下沉为平台基础设施，实现应用与平台基础设施的解耦。

通过Service Mesh化，开发者无需关注微服务相关治理问题而聚焦于业务逻辑本身，从而提升应用开发效率并加速业务探索和创新。同时，因为大量非功能性从业务进程剥离到独立进程中，Service Mesh 以无侵入的方式实现了应用轻量化。

下图展示了 Service Mesh 的 典型架构：

3.6 DevOps

DevOps 就是为了提高软件研发效率，快速应对变化，持续交付价值的的一系列理念和实践，其基本思想就是持续部署（CD)，让软件的构建、测试、发布能够更加快捷可靠，以尽量缩短系统变更从提交到最后安全部署到生产系统的时间。

IaC 和 GitOps

DevOps 所面对的矛盾就是开发和运维团队之间的矛盾。因为两个团队的关注点完全不同，或者说 是冲突的。在这种背景下，IaC（Infrastructure as Code） 提出系统建设的核心理念，兼顾高效和安全，让运维系统的建设更加有序。

运维平台的两类实现方式：

• 指令式
• 声明式

声明式接口是一种和云计算时代相契合的思维范式。几个主要优势：幂等性、变更审核简单明了、复杂性抽象。

GitOps 作为 IaC 运维理念的一种具体落地方式，就是使用 Git 来存储关于应用系统的最终状态的声明式描述。GitOps 的核心是一个 GitOps 引擎，它负责监控 Git 中的状态，每当它发现状态有改变，它就负责把目标应用系统中的状态以安全可靠的方式迁移到目标状态，实现部署、升级、配置修改、回滚等操作。

和 GitOps 配套的一个基本假设是不可变基础设施，所以 GitOps 和 Kubernetes 运维可以非常好的配合。

云原生时代的 DevOps

一个完整开发流程涉及到很多步骤，而环节越多，一次循环花费的时间越长，效率就越低。微服务通过把巨石 应用拆解为若干单功能的服务，减少了服务间的耦合性，让开发和部署更加便捷，可以有效降低开发周期，提高 部署灵活性。Service Mesh 让中间件的升级和应用系统的升级完全解耦，在运维和管控方面的灵活性获得提升。 Serverless 让运维对开发透明，对于应用所需资源进行自动伸缩。FaaS 是 Serverless 的一种实现，则更加简化 了开发运维的过程，从开发到最后测试上线都可以在一个集成开发环境中完成。无论哪一种场景，后台的运维平台的 工作都是不可以缺少的，只是通过技术让扩容、容错等技术对开发人员透明，让效率更高。

3.7 云原生中间件

在云原生时代，传统中间件技术也演化升级为云原生中间件，云原生中间件主要包括网格化的服务架构、事件驱 动技术、Serverless 等技术的广泛应用。云原生中间件最大的技术特点就是中间件技术从业务进程中分离，变成与开发语言无关的普惠技术，只与应用自身架构和采用的技术标准有关。

微服务架构一般包含下列组件：服务注册发现中心、配置中心、服务治理、服务网格、API 管理、运行时监控、 链路跟踪等。随着 Kubernetes 的流行，Kubernetes 提供的基础部署运维和弹性伸缩能力已经可以满足多数中小 企业的微服务运维要求。微服务与 Kubernetes 集成会是一个大趋势。

服务注册发现和配置中心的功能主要致力于解决微服务在分布式场景下的服务发现和分布式配置管理两个核心问题。随着云原生技术的发展，服务发现领域出现了两个趋势，一个是服务发现标准化（Istio），一个是服务下沉 (CoreDNS)；配置管理领域也有两个趋势，一个是标准化（ConfigMap），一个是安全 (Secret)。

提到事件驱动就必须先讲消息服务，消息服务是云计算 PaaS 领域的基础设施之一，主要用于解决分布式应 用的异步通信、解耦、削峰填谷等场景。消息服务提供一种 BaaS 化的消息使用模式，用户无需预先购买服务器 和自行搭建消息队列，也无需预先评估消息使用容量，只需要在云平台开通即用，按消息使用量收费。

事件驱动架构：由于 IoT、云计算技术的快速发展，事件驱动架构在未来将会被越来越多的企业采纳，通过事件的抽象、异步化，来提供业务解耦、加快业务迭代。在过去事件驱动架构往往是通过消息中间件来实现，事件用 消息来传递。

4. 阿里巴巴云原生架构设计

ACNA（Alibaba Cloud Native Architecting）架构设计方法。ACNA 是一个 「4+1」 的架构设计流程，「4」 代表架构设计的关键视角，包括企业战略视角、业 务发展视角、组织能力视角和云原生技术架构视角；「1」 表示云原生架构的架构持续演进闭环。示例图如下（非常高屋建瓴的感觉）：

5. 阿里巴巴云原生产品介绍

阿里巴巴云原生产品家族包括容器产品家族、微服务产品家族、Serverless 产品家族、Service Mesh 产品家族、消息产品、云原生数据库家族、云原生大数据产品家族等。大图如下（进入广告时间）：

6. 各个行业面临的挑战及解决方案

不同行业采用阿里云的云原生技术、云原生架构，助力企业的技术创新和企业的数字化转型。

给了几个例子：申通（物流）、完美日记（电商）、特步（零售）、中国联通（通信）、Timing App（App）。

7. 云原生架构未来发展趋势

3.1 容器技术发展趋势

• 趋势一：无处不在的计算催生新一代容器实现（强调安全可信、跨平台）
• 趋势二：云原生操作系统开始浮现（Kubernetes 已经成为云时代的操作系统。）

传统意义的操作系统和云原生操作系统的对比：

• 趋势三： Serverless 容器技术逐渐成为市场主流
• 趋势四：动态、混合、分布式的云环境将成为新常态

3.2 基于云原生的新一代应用编程界面

Kubenetes 已经成为了云原生的操作系统，而容器成为了操作系统调度的基本单元，同时定义了应用交付的标准。但是对于应用开发者来说，这些还远没有深入到应用的架构，改变应用的编程界面。

几个主要的变革：

• Sidecar 架构彻底改变了应用的运维架构。

• 应用生命周期全面托管。

• 用声明式配置方式使用云服务。

• 语言无关的分布式编程框架成为一种服务。

包括生命周期管理、运维管理、配置范围和扩展和管理、以及语言无关的编程框架，一起构成了崭新的应用与云之间的编程界面。

3.3 Serverless 发展趋势

• 趋势一：Serverless 将无处不在。

• 趋势二：Serverless 将通过事件驱动的方式连接云及其生态中的一切。

• 趋势三：Serverless 计算将持续提高计算密度，实现最佳的性能功耗比和性能价格比。

python（以及他的库）是很庞大有用的。他可以用来做系统自动化、web应用、大数据、数据分析以及安全软件。这篇文章旨在说明一些可以帮你更快更好地开发、debug的鲜为人知的小技巧。 对于每一种语言来说，一旦你学了这个语言，你真正得到的并不是这个语言本身的特性能力，而是你学会他的编程风格、学会用他的库以及python社区里的知识。

探索标准数据类型

低调的enumerate

迭代python里的任何内容都是很容易的，你只要这样就行了：for foo in bar:

drinks=["coffee","tea","milk","water"]
for drink in drinks:
  print("thirsty for",drink)
#thirsty for coffee
#thirsty for tea
#thirsty for milk
#thirsty for water

但是除了这些items之外，我们经常也会需要知道item的index。我们经常会看到一些程序员通过len()和range() 用index迭代一个list，这里有一种更简单的方式：

drinks=["coffee","tea","milk","water"]
for index, drink in enumerate(drinks):
    print("Item {} is {}".format(index,drink))
#Item 0 is coffee
#Item 1 is tea
#Item 2 is milk
#Item 3 is water

内建的enumerate方法生成了index以及item。

集合

有很多的场景是可以归结到集合操作的。我们需要确保list没有重复元素？需要看两个list有哪些共同项？python的set类型可以让这些操作更快并且更可读的。

# deduplicate a list *fast*
print(set(["ham","eggs","bacon","ham"]))
# {'bacon', 'eggs', 'ham'}

# compare lists to find differences/similarities
# {} without "key":"value" pairs makes a set
menu={"pancakes","ham","eggs","bacon"}
new_menu={"coffee","ham","eggs","bacon","bagels"}
new_items=new_menu.difference(menu)
print("Try our new",", ".join(new_items))
# Try our new bagels, coffee
discontinued_items=menu.difference(new_menu)
print("Sorry, we no longer have",", ".join(discontinued_items))
# Sorry, we no longer have pancakes

old_items=new_menu.intersection(menu)
print("Or get the same old",", ".join(old_items))
# Or get the same old eggs, bacon, ham
full_menu=new_menu.union(menu)
print("At one time or another, we've served:",", ".join(full_menu))
# At one time or another, we've served: coffee, ham, pancakes, bagels, bacon, eggs

intersection函数比较所有的items，然后只把两个集合里都有的items返回。

collections.namedtuple

当你不需要类的方法，但是又想要foo.prop这样的简便时，没有什么比namedtuple更好了。你可以提前定义fields，然后初始化一个比完整对象占用内存更少的轻量级的类。

LightObject=namedtuple('LightObject',['shortname','otherprop'])
m=LightObject()
m.shortname='athing'
> Traceback(most recent call last):
> AttributeError:can't set attribute

就像你不能改变一个tuple的成员一样，你也不能设置namedtuple的属性。你需要做的是当你初始化namedtuple时设置他的属性。

LightObject=namedtuple('LightObject',['shortname','otherprop'])
n=LightObject(shortname='something',otherprop='something else')
n.shortname# something

collections.defaultdict

在python app里我们经常会看到这样的逻辑：我们需要去考虑key初始时是不是存在，类似这样：

login_times = {}
for t in logins:
    if login_times.get(t.username, None):
        login_times[t.username].append(t.datetime)
    else:
        login_times[t.username] = [t.datetime]

通过defaulltdict我们可以跳过上面的逻辑，直接访问undefined key。

login_times = collections.defaultdict(list)
for t in logins:
    login_times[t.username].append(t.datetime)

你甚至可以自定义类，给出构造函数去build一个类。

from datetime import datetime
class Event(object):
    def __init__(self, t=None):
    if t is None:
        self.time = datetime.now()
    else:
        self.time = t
events = collections.defaultdict(Event)
for e in user_events:
    print(events[e.name].time)

除了用defaultdict，我们可以用addict去设置嵌套的key。

normal_dict = {
    'a': {
        'b': {
            'c': {
                'd': {
                    'e': 'really really nested dict'
                }
            }
        }
    }
}

from addict import Dict
addicted = Dict()
addicted.a.b.c.d.e = 'really really nested'
print(addicted)
# {'a': {'b': {'c': {'d': {'e': 'really really nested'}}}}}

这段代码比标准的dict更简单，那么defaultdict可以吗？看起来应该可以。

from collections import defaultdict 
default = defaultdict(dict) 
default['a']['b']['c']['d']['e'] = 'really really nested dict' # fails

这样看起来应该是可以的，但是他抛出了KeyError异常，因为default['a']是一个dict，不是defaultdict 如果你只是需要一个counter，你可以用collections.Counter来提供像most_common这样的功能。

控制流

当我们学习python里面的控制结构的时候，通常我们会接触到for，while，if-elif-else，以及try-except。合理地利用这些控制结构我们可以解决绝大多数的问题。不过python也提供了一些其他不常用的结构，这些结构有时可以让你的代码可读性更好，而且更易于维护。

异常处理

当处理数据库，sockets，文件或者任何其他处理时可能失败的资源时，Exception是一种很常见的流程控制模式。通过标准的try except，比如操作数据库：

try:
    # get API data
    data = db.find(id='foo') # may raise exception
    # manipulate the data
    db.add(data)
    # save it again
    db.commit() # may raise exception
except Exception:
    # log the failure
    db.rollback()

db.close()

你可以指出这段代码的问题吗？ 这里有两个可能出现的异常，他们会触发相同的except代码块。这意味着find数据失败会引起rollback。这绝不是我们希望的，因为在那个点发生的异常甚至还没有开始一个数据库事务。对于一个连接失败来说，rollback并不是一个正确的处理方式，所以我们要把上面的代码拆分开来。 首先我们需要处理find数据。

try:
    # get API data
    data = db.find(id='foo') # may raise exception
except Exception:
    # log the failure and bail out
    log.warn("Could not retrieve FOO")
    return

# manipulate the data
db.add(data)

现在取数据有他自己的try-except了。如果没有数据我们的代码也没有什么可以做的了，所以我们可以退出函数或者我们也可以创建一个默认对象然后重试这个query，或者kill整个程序。 现在，我们处理commit。

try:
    db.commit() # may raise exception
except Exception:
    log.warn("Failure committing transaction, rolling back")
    db.rollback()
else:
    log.info("Saved the new FOO")
finally:
    db.close()

这里我们加了两句话。首先我们看else，当没有异常时会执行他。在我们的例子里面，他只是在日志里打了事务成功，但是你也可以根据需要放些需要的行为。比如你可能会执行一个后台的job或者一个通知。 这里finally是为了确保db.close()总能执行的。我们可以看到我们所有的代码都是跟commit这个操作绑在一起的。

上下文和控制流程

我们已经看到了上面怎么用exceptions去控制流程。总的来说步骤如下： 1. Attempt to acquire a resource (file, network connection, whatever) 2. If it fails, clean up anything left behind 3. Otherwise, perform actions on the resource 4. Log what happened 5. Program complete

知道这个以后，我们用第二种方法来处理前面的数据库的例子。我们用try-except-finally来确保任何事务要么就committed，要么就rolled back。

try:
    # attempt to acquire a resource
    db.commit()
except Exception:
    # If it fails, clean up anything left behind
    log.warn("Failure committing transaction, rolling back")
    db.rollback()
else:
    # If it works, perform actions
    # In this case, we just log success
    log.info("Saved the new FOO")
finally:
    # Clean up
    db.close()
# Program complete

我们之前的例子就是上面这几步，那么我们可以对这个逻辑做些什么修改呢？ 对于每次我们保存数据，我们都需要准确地执行上面的这些步骤。所以我们可以把这些逻辑放进方法里，或者我们可以用一个上下文管理器。

db = db_library.connect("fakesql://")
# as a function
commit_or_rollback(db)

# context manager
with transaction("fakesql://") as db:
    # retrieve data here
    # modify data here

待续