暂时未有相关云产品技术能力~
暂无个人介绍
在繁琐的业务流程处理中,通常采用面向过程的设计方法将流程拆分成N个步骤,每个步骤执行独立的逻辑。但是这样剥离仍然不彻底,修改其中一个步骤仍然可能影响其他步骤。在这种场景下,有一种经典的设计模式-责任链模式,可以将这些子步骤封装成独立的handler,然后通过pipeline将其串联起来。
单元测试是软件开发过程中的重要一环,好的单测可以帮助我们更早的发现问题,为系统的稳定运行提供保障。单测还是很好的说明文档,我们往往看单测用例就能够了解到作者对类的设计意图。代码重构时也离不开单测,丰富的单测用例会使我们重构代码时信心满满。
阿里云日志服务作为云原生可观测与分析平台。提供了一站式的数据采集、加工、查询分析、可视化、告警、消费与投递等功能。全面提升用户的研发、运维、运营、安全场景的数字化能力。日志服务平台作为可观测性平台提供了数据导入、数据加工、聚集加工、告警、智能巡检、导出等功能,这些功能在日志服务被称为任务,并且具有大规模的应用,接下来主要介绍下这些任务的调度框架的设计与实践。
去年的Log4j-core的安全问题,再次把供应链安全推向了高潮。在供应链安全的场景,蚂蚁集团在静态代码扫描平台-STC和资产威胁透视平台-哈勃这2款产品在联合合作下,优势互补,很好的解决了直接依赖和间接依赖的场景。但是由于STC是基于事前,受限于扫描效率存在遗漏的风险面,而哈勃又是基于事后,存在修复时间上的风险。基于此,笔者尝试寻找一种方式可以同时解决2款产品的短板。
关于并行查询的功能、特性、技术原理等,"并行查询的前世今生"这篇已做过详细的解读,今天这篇文章则主要聚焦于并行查询全新发布的下一代形态:弹性多机并行(Elastic Parallel Query)。
在我看来并不是MVC的基础上增加领域层,使用充血模型,解耦基础服务,我的代码就符合DDD了。
个人认为一个好的方法主要表现在可读性、可维护性、可复用性上,本文通过设计原则和代码规范两章来讲解如何提高方法的可读性、可维护性、可复用性。这些设计原则和代码规范更多的是表现一种思想,不仅仅可以用在方法上,也可以用在类上、模块上。下面通过具体的例子来讲解。
本文为钛媒体联合创始人刘湘明与阿里云智能数据库事业部负责人李飞飞对话节选。
本文总结提炼了Alibaba.com App的瘦身的技术和策略,系统化地介绍APP瘦身的业务价值、分析技术、瘦身技术、防劣化机制,让读者可以系统化地了解APP瘦身的技术体系。并基于实践经验,介绍各种瘦身技术的ROI,让读者可以避免踩雷,将资源浪费在效果不佳的技术上。希望对你有所帮助。
安全是产品的底座,是体验的基础,也是企业的一项核心竞争力。安全生产是一项系统性的工作,同时也是一件比较琐碎的事,需要做方方面面的考虑尽一切可能保障系统安全稳定运行。
性能优化显而易见的好处是能够节约机器资源。如果一个有2000台服务器的应用,整体性能提升了10%,理论上来说,就相当于节省了200台的机器。除了节省机器资源外,性能好的应用相对于性能差的应用,在应对流量突增时更不容易达到机器的性能瓶颈,在同样流量场景下进行机器扩容时,也只需要更少的机器,从而能够更快的完成扩容、应急操作。所以,性能好的应用相对于性能差的应用在稳定性方面也更胜一筹。
2021年初,OpenAI 团队发布了能够根据文本描述生成图像的 DALL-E 模型。由于其强大的跨模态图像生成能力,引起自然语言和视觉圈技术爱好者的强烈追捧。仅仅一年多的时间,多模态图像生成技术如雨后春笋般开始涌现。本文从技术兴趣出发,对多模态图像生成技术与经典工作进行介绍,最后探索如何使用多模态图像生成进行神奇的 AI 绘画艺术创作。
过去5年,阿里云针对PolarDB进行了诸多创新,通过采用存储计算分离、软硬一体化设计,PolarDB实现成本仅为传统商业数据库的十分之一。所实现的计算、内存与存储资源的“三层解耦”架构、多主多写、基于IMCI(内存列存索引)的HTAP、Serverless等功能已是全球首创或业内领先的技术。从PolarDB发布以来,它在技术和商业化上都获得了迅猛发展,如今已经成为阿里云数据库产品家族中最闪耀的产品。本文我们将向大家详细介绍,PolarDB发布5年来所实现的技术创新。
本篇文章主要讲解如何从一个空目录开始,建立起一个基于webpack + react + typescript的标准化前端应用。
本文将阐述通过基础设施与工具的改进,实现从构建到启动全方面大幅提速的实践和理论。
为什么测试环境的不稳定是必然的,怎么让它尽量稳定一点?为什么测试环境比生产环境更复杂,怎么让它尽量简单一点?本文将就这两点进行分享。同时,还会谈一谈对测试环境和生产环境的区别的理解。
一个单元测试是一段自动化的代码,这段代码调用被测试的工作单元,之后对这个单元的单个最终结果的某些假设进行校验。单元测试几乎都是用单元测试框架编写的;只要产品代码不发生变化,单元测试的结果是稳定的。那么如何写出有效的单元测试呢?
2022年6月底,阿里云iLogtail代码完整开源,正式发布了完整功能的iLogtail社区版。iLogtail作为阿里云SLS官方标配的采集器,多年以来一直稳定服务阿里集团、蚂蚁集团以及众多公有云上的企业客户,目前已经有千万级的安装量,每天采集数十PB的可观测数据,广泛应用于线上监控、问题分析/定位、运营分析、安全分析等多种场景。此次完整开源,iLogtail社区版首次在内核能力上与企业版完全对齐,开发者可以构建出与企业版性能相当的iLogtail云原生可观测性数据采集器。
作者在负责菜鸟商业中心CRM系统开发过程中发现有一个痛点:业务线很多,每个业务线对同一个页面都有个性化布局和不同的字段需求,而他所在的团队就3个人,那么在资源有限的情况下该如何支撑呢?本文就降本的情况下,和大家分享下作者是如何低成本构建产品能力去支撑多条业务线、多租户的。
我们一直在说系统很复杂,那到底什么是系统复杂度呢?作为团队的稳定性底盘负责人,也经常和大家探讨为什么会因为圈复杂度高而被扣分。那么,怎么才能写的一手可读,可扩展,可维护的好代码?本文作者尝试结合在团队内部的实践,分享下过程中心得。
想知道内核研发是怎样的体验?操作系统的“冷板凳”得坐多久才有春天?本文对话龙蜥社区理事长马涛,畅所欲言聊开源,一起来看看那些开源润物细无声背后的故事以及龙蜥社区运营的道法术。
在写Java代码的时候,最烦写setter/getter方法,自从有了Lombok插件不用再写那些方法之后,感觉再也回不去了,那你们是否好奇过Lombok是怎么把setter/getter方法给你加上去的呢?有的同学说我们Java引入Lombok之后会污染依赖包,那我们可不可以自己写一个工具来代替Lombok呢?
Fury是一个基于JIT动态编译的多语言原生序列化框架,支持Java/Python/Golang/C++等语言,提供全自动的对象多语言/跨语言序列化能力,以及相比于别的框架最高20~200倍的性能。
随着eBPF推出,由于具有高性能、高扩展、安全性等优势,目前已经在网络、安全、可观察等领域广泛应用,同时也诞生了许多优秀的开源项目,如Cilium、Pixie等,而iLogtail 作为阿里内外千万实例可观测数据的采集器,eBPF 网络可观测特性也预计会在未来8月发布。下文主要基于eBPF观测HTTP 1、HTTP 1.1以及HTTP2的角度介绍eBPF的针对可观测场景的应用,同时回顾HTTP 协议自身的发展。
我们团队在手淘中主要负责BehaviX模块,代码主要是一些逻辑功能,很少涉及到UI,为了减少双端不一致问题、提高性能,我们采用了将核心代码C++化的策略。由于团队项目偏底层,测试同学难以完全覆盖,回归成本较高,部分功能依赖研发同学自测,为了提高系统的稳定性,我们在团队中实行了单元测试,同时由于集团客户端C++单元测试相关经验沉淀较少,所以在此分享下团队在做单元测试中遇到的问题与解决思路,希望能对大家所有帮助。
资源预测是项目管理过程中的一个环节,即通过搭建合适的数据模型,对未来的项目人力资源投入情况进行有效预测,可以更加精准的完成项目资源规划并能及时发现问题进行相关调整。
重构代码时,我们常常纠结于这样的问题:需要进一步抽象吗?会不会导致过度设计?如果需要进一步抽象的话,如何进行抽象呢?有什么通用的步骤或者法则吗?为了保证直观,本文将以一个 “生产者消费者” 的代码重构示例贯穿始终。最后还会以业务上常见的 Excel 导出系统为例简单阐述一个业务上的重构实例。
本文简要介绍文图生成的技术,以及如何在EasyNLP框架中如何轻松实现文图生成,带你秒变艺术家。本文开头的展示图片即为我们模型创作的作品。
本人在设计和落地基于Go原生插件机制的扩展开发产品时踩到了很多坑,由于这方面相关资料很少,因而借此机会做一个非常粗浅的总结,希望能对大家有所帮助。本文只说问题和解决方案,不读代码。
很多时候,我们一直在思考如何高效支撑业务这个课题上。阿里技术分享平台或者网上都有非常多的文章分享,每个TL针对自己团队的状况也有一套自己的方法论。本文作者将结合自己所面临的状况,把自己的思考总结分享给大家。
在设计代码目录划分方案的过程中,看了一些工程结构设计的资料,读了一些关于架构设计的书,对于架构有了一些理解。本文是对这段学习和任务完成过程的思考和沉淀。希望能够解答“架构到底是什么?架构和业务之间的关系?”,“好的架构的设计出发点是什么?好的架构应该是什么样的?”这几个问题。