大家好，我是语雀 QA 会能。 很高兴，有机会跟大家聊一下语雀的质量体系和自动化技术。 下面会分几个部分给大家介绍，让大家可以了解到语雀质量体系的全貌。
表格存储Tablestore上线已有十年，随着业务规模变大，稳定性挑战也随之而来，需要不断优化架构来提升可用性。本文将为大家分享表格存储Tablestore在技术层面近年来的功能演进、技术架构演进以及稳定性优化相关的工作，以及在业务层面我们定义的核心应用场景和一些典型案例。
1月11日，达摩院2023十大科技趋势发布，生成式AI、Chiplet模块化设计封装、全新云计算体系架构等技术入选。达摩院认为，全球科技日趋显现出交叉融合发展的新态势，尤其在信息与通信技术（ICT）领域酝酿的新裂变，将为科技产业革新注入动力。 颠覆性的科技突破也许百年才得一遇，持续性的迭代创新则以日进一寸的累积改变着日常生活。进入2023年，达摩院预测，基于技术迭代与产业应用的融合创新，将驱动AI、云计算、芯片等领域实现阶段跃迁。 AI正在加速奔向通用人工智能。多模态预训练大模型将实现图像、文本、音频等的统一知识表示，成为人工智能基础设施；生成式AI将迎来应用大爆发，极大推动数字化内容的生产与创造。人工智能诞生数十年，人类对“通用AI”的想象从未如此具体。
Blink提交采用进程模型（包装flink info/run命令）进行作业执行计划的生成和作业的提交，这个基本是大数据计算引擎jstorm/spark/flink的共识，采用该方式的优点在于： 简单： 用户只需在自己的jar包中进行逻辑处理 引擎client负责以方法调用形式调用用户main方法，然后编译、提交 干净 进程模型用户包用完销毁，引擎版本包通过目录隔离，不用考虑多版本问题。 但这也带来了缺点，每次都得走一遍大量class 加载、校验等jvm启动全流程。同时，大多数作业的的执行计划生成耗时是在20秒以内，也就是说此时瓶颈不在编译阶段，此时jvm启动开销就成为了瓶颈。尤其当这些操作极其高频时，带来的开销不容小视。
目前闲鱼行业产品有回收、寄卖、验货宝等，这些产品在基础交易模式上引入附加玩法规则，其状态机相比于普通交易模型更加灵活复杂。基础交易模型订单状态只包含：创建订单->付款->发货->确认收货 。以回收举例，在中台基础交易模型之上，又附加了诸多行业业务状态，如服务商收货、质检、用户确认质检等。这些状态，是通过用户或服务商等多种角色推进的，而业务状态的维护也需要闲鱼自己来负责。
钉钉单元化从2018年开始到今年已经是第五个年头了，五年的时间，钉钉单元化迭代了三个版本，从最初的毛头小子，到达今年已经小有成就。今天想借这个场来和大家分享我们单元化的心路历程和一些最佳实践。本文要分享的内容只涉及部分内容，无法做到面面俱到，主要是想在同路人中形成共鸣，进而能复用一些架构或者系统。在我们单元化建设过程中，除了网上仅有的文章外，其可以直接使用的系统乏善可陈，使我们不得不从最基础的系统开始，极大的影响建设效率。幸运最近几年云原生技术的兴起，让我们能复用很多基础设施，进而快速的提升我们单元化能力，助力钉钉的发展。
2022 年，大淘宝前端团队进行了调整：重新组织生产关系，按业务线拆分整合进对应的业务技术团队，同时保留了大前端虚线组织，确保研发基建的一致性、技术的持续投入以及推进人员的成长。 整个变化涉及超过三百人的前端团队，经过了半年多的运转，整个团队在技术上也进行了对应的聚焦和收敛。 新的组织协作形态下，大淘宝 Web 领域的工程师们正在做哪些技术工作、有什么技术产品，特在 2023 年开年之际向行业前端同学进行分享。
稳定性是个啥？ 第一次接触稳定性这个词是在加入阿里第一年的双十一KO会上。接触到限流、扩容、压测等词汇，只觉得稳定性工作是琐碎的、繁杂的、无流程性的、无明确衡量指标的、无从下手的。 今年，我和两个小伙伴一起在稳定性保障工作中投入了大量的精力，我也从他们那里学到了不少关于稳定性保障相关知识，开始对稳定性工作有了一定的理解。 稳定性工作也是有条理有步骤的，按照步骤一步步来，就能够轻松将稳定性保障工作做全、做对、做好。 所谓好记性不如烂笔头。趁机梳理记录下来，以便后续使用时能够信手拈来。
Chrome 在去年成立了一个名为 Aurora[1] 的项目，深入主流的框架和工具，比如 next.js、nuxt、 angular、webpack 等，探索如何结合框架和工具，帮助 Web 开发者用更低的成本，构建出更好的体验。 ice.js 虽不在这个项目之中，却也是在设计之初就秉持着这种理念，来实现整个框架的。无论是路由方案、数据加载方案、渲染方案，都是围绕着体验而设计。这是因为，我们都越来越意识到，框架掌控着整个应用的生命周期，是最适合从流程上来做出优化、提升体验的。好的体验，应该成为业务开发时的一个顺其自然的产物。 反观目前，我们的 Web 体验则还是一种 开发者重参与的模式，这种方式往往是： 先开发后治理，在完成业务开发，甚至上线后，再进行性能的评估，分析诊断优化点，实施相应的优化策略 对开发者要求高，需要每个开发者都能熟练分析各种性能问题，掌握各类场景的体验优化方案 不可持续，容易随着业务迭代又发生退化 如何改变现状，借助于框架设计，普遍提升业务的体验基线，而不必要求人人成为 Web 体验的专家，这正是 ice.js 3 在探索解决的问题。
