微博热搜榜 排名 1.中国改革开放的信心和意志都不会动摇 排名 2.董宇辉成东方甄选高级合伙人 排名 3.韩国大量进口中国辣椒酱 排名 4.双曲线一号商业运载火箭成功发射 排名 5.赵露思上台忘记脱毛衣了 排名 6.倪妮周雨彤 体面 排名 7.刘畊宏出圈1年多后谈流量下滑 排名 8.我的面子未塌房 排名 9.迪丽热巴领奖走成T台 排名 10.日本死鱼多到渔船寸步难行 排名 11.出道六年她占五年 排名 12.上海下雪 排名 13.东方甄选已承诺董宇辉天价待遇 排名 14.吴磊发言切赵露思 排名 15.今天的朋友圈格外emo 排名 16.罗永浩 铁公鸡和马屁精的故事 排名 17.张万森 朋友圈下老登了 排名 18.王一博到底在急什么 排名 19.迪丽热巴王鹤棣同框 排名 20.杨紫于和伟 年度电视剧演员 GitHub 热门榜单 排名 1:/anoma/namada 简介: Namada的Rust实现，用于链间资产无关隐私的权益证明L1 URL: https://github.com/anoma/namada 作者: anoma 排名 3:/HumanAIGC/OutfitAnyone 简介: Outfit Anyone：任何服装和任何人的超高质量虚拟试穿 URL: https://github.com/HumanAIGC/OutfitAnyone 作者: HumanAIGC 排名 4:/SagerNet/sing-box 简介: 通用代理平台 URL: https://github.com/SagerNet/sing-box 作者: SagerNet 排名 6:/lobehub/lobe-chat 简介: 🤖Lobe Chat-一个开源、高性能的聊天机器人框架，支持语音合成、多模式和可扩展的函数调用插件系统。支持一键免费部署您的私人ChatGPT/LLM web应用程序。 URL: https://github.
微博热搜榜 排名 1.总书记这一内外联动的行程有深意 排名 2.罗永浩炮轰东方甄选 排名 3.乌克兰或在明年3月前破产 排名 4.自主研制飞机C919环绕香港岛做演示 排名 5.俞敏洪称天权失态让他愤怒 排名 6.丈夫去世7名好友帮照顾家庭6年 排名 7.刘诗诗说一念关山不是古偶 排名 8.俞敏洪正策划带董宇辉去国外直播 排名 9.以军误杀3名以色列人细节曝光 排名 10.你们俩这么亲我就不困了 排名 11.董宇辉粉丝突破2000万 排名 12.看小说时的生理反应 排名 13.文章39岁状态 排名 14.俞敏洪称孙东旭还能参加公司沟通发展 排名 15.东方甄选事件谁动了谁的蛋糕 排名 16.杨幂和30斤裙子度过一天 排名 17.女子遭丈夫打断腰椎住院后被砍数刀 排名 18.为什么女生一生气就不讲话 排名 19.张凌赫全开麦 一开口我人傻了 排名 20.谁能管管赵露思和王安宇 GitHub 热门榜单 排名 1:/AvaloniaUI/Avalonia 简介: 使用C#和XAML开发桌面、嵌入式、移动和WebAssembly应用程序。最受欢迎的。NET基金会社区项目。 URL: https://github.com/AvaloniaUI/Avalonia 作者: AvaloniaUI 排名 2:/lobehub/lobe-chat 简介: 🤖Lobe Chat-一个开源、高性能的聊天机器人框架，支持语音合成、多模式和可扩展的函数调用插件系统。支持一键免费部署您的私人ChatGPT/LLM web应用程序。 URL: https://github.com/lobehub/lobe-chat 作者: lobehub 排名 3:/microsoft/promptbase 简介: 一切促使工程 URL: https://github.com/microsoft/promptbase 作者: microsoft 排名 4:/google/generative-ai-swift 简介: Swift的Google AI SDK URL: https://github.
微博热搜榜 排名 1.习近平访越高光时刻 排名 2.给住院婆婆吃泡面博主发声 排名 3.生产商称从未生产过小杨哥带货牛肉卷 排名 4.如果中国县城变身各科课代表 排名 5.东方甄选停播一天闭门思过 排名 6.黄子弘凡 四级 排名 7.工作是为了早点赎身 不是干成头牌 排名 8.酷家vocal级别名台词 排名 9.赵文卓 演员迟到成常规了 排名 10.什么菜公摊面积那么大 排名 11.上海下雪 排名 12.沙溢有沙溢但沙溢忍了 排名 13.东方甄选主播天权摔手机 排名 14.罗永浩爆料有人出5亿违约金挖董宇辉 排名 15.东方甄选25分钟掉粉10万 排名 16.余秀华建议俞敏洪给董宇辉单独搞团队 排名 17.董宇辉账号粉丝数接近东方甄选一半 排名 18.会计和猪最怕过年 排名 19.萌兰给自己整了一个屁帘儿 排名 20.罗永浩称企业出来公关不要爹头爹脑 GitHub 热门榜单 排名 1:/lobehub/lobe-chat 简介: 🤖Lobe Chat-一个开源、高性能的聊天机器人框架，支持语音合成、多模式和可扩展的函数调用插件系统。支持一键免费部署您的私人ChatGPT/LLM web应用程序。 URL: https://github.com/lobehub/lobe-chat 作者: lobehub 排名 2:/microsoft/promptbase 简介: 一切促使工程 URL: https://github.com/microsoft/promptbase 作者: microsoft 排名 3:/HumanAIGC/OutfitAnyone 简介: Outfit Anyone：任何服装和任何人的超高质量虚拟试穿 URL: https://github.
微博热搜榜 排名 1.习近平在广西南宁考察调研 排名 2.孟羽童个人简介是前500强董事长秘书 排名 3.流星雨 排名 4.改革开放45年看湾区 排名 5.家人们这波稳了 排名 6.董宇辉 孟羽童 排名 7.有文科生博主欲起诉张雪峰 排名 8.学校花1500万买下空客A320给学生练手 排名 9.电影三大队今日上映 排名 10.东方甄选回应董宇辉停播 排名 11.哈妮 你也是叫哈妮克孜吗 排名 12.普京打断让美记者发言要求话筒先给新华社 排名 13.一念关山27集剪辑 排名 14.记者举报洗浴提供色情服务后被警方回怼 排名 15.北京地铁昌平线两区段维持运营 排名 16.中1.44亿元彩民中奖号码已守3年 排名 17.女生称遭男童袭胸老人护孙摔断腰椎 排名 18.元梦之星广场全是熟人 排名 19.林心如聊霍建华求婚过程 排名 20.董宇辉曾拒绝2亿年薪挖角 GitHub 热门榜单 排名 1:/lobehub/lobe-chat 简介: 🤖Lobe Chat-一个开源、高性能的聊天机器人框架，支持语音合成、多模式和可扩展的函数调用插件系统。支持一键免费部署您的私人ChatGPT/LLM web应用程序。 URL: https://github.com/lobehub/lobe-chat 作者: lobehub 排名 2:/Mintplex-Labs/anything-llm 简介: 开源和闭源LLM、嵌入程序和矢量数据库的开源ChatGPT经验。在一个应用程序中拥有权限管理的无限文档、消息和并发用户。 URL: https://github.com/Mintplex-Labs/anything-llm 作者: Mintplex-Labs 排名 3:/microsoft/promptbase 简介: 一切促使工程 URL: https://github.com/microsoft/promptbase 作者: microsoft 排名 4:/nishuzumi/pow-erc20 简介: PowerERC20的铸造者 URL: https://github.
单元测试的价值 单元测试是一种白盒测试技术，通常由开发人员在编码阶段完成，目的是验证软件代码中的每个单元（方法或类等）是否符合预期，即尽早在尽量小的范围内暴露问题。
我们都知道，问题发现得越早，修复的代价越小。毫无疑问，在开发阶段进行正确的单元测试可以极大地节省时间和金钱。如果跳过单元测试，会导致在后续更高级别的测试阶段产生更高的缺陷修复成本。
如图，假如有一个只包含两个单元 A 和 B 的程序，且只执行端到端测试，如果在测试过程中发现了缺陷，则可能有如下多种原因：
该缺陷由单元 A 中的缺陷引起；
该缺陷由单元 B 中的缺陷引起；
该缺陷由单元 A 和单元 B 中的缺陷共同引起；
该缺陷由单元 A 和单元 B 之间接口的缺陷引起；
该缺陷是测试方法或测试用例的错误导致的。
由此可见，忽略单元测试会导致后续发现缺陷时，要花费较高的成本来确认缺陷原因。
单元测试除了能够在较早阶段识别软件中的错误，它还有如下价值。
反馈速度快：单元测试通常以自动化形式运行，执行速度非常快，可以快速反馈结果，跟持续集成结合起来，形成有效的反馈环。
重构的有力保障：系统需要大规模重构时，单测可以确保对已有逻辑的兼容，如果单元测试都通过，基本上可以保证重构没有破坏原来代码逻辑的正确性。
使更熟悉代码：写单元测试的过程本身就是一个审视代码的过程，可以发现一些设计上的问题（代码设计的不可测试）、代码编写方面的问题（边界条件的处理不当）等。
既然单元测试由开发人员来设计和执行，那作为测试人员是不是就不需要学习这门技术了？不知道你是怎样看待这个想法的，我的观点是：
单元测试只是通常情况下由开发人员完成，并不是绝对的，在一些公司或项目里也存在测试人员完成的情况；
在你负责的模块或服务里，第一级别的测试不是你来完成的，那么你更有必要去了解它的设计思路和执行情况，这能帮助你发现单元测试可能存在的问题点，也有利于你设计和执行后续高级别的测试类型；
开发人员总是不太擅长做测试类的工作，当你掌握了单元测试的技能，你便更有机会去帮助和影响到开发人员，赢得他对你的尊重，也有利于你们更好地合作；
这种想法是测试人员的常见想法，所以掌握单元测试技能在测试人员群体中也会是稀缺技能，因此，掌握它将会获得额外的锻炼机会和个人影响力，要知道，机会总是留给有准备的人。
微服务下的单元测试类型 就像之前课程所说：微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，服务与服务之间常常互相调用以实现更多更复杂的功能。
举个例子，我们需要测试的是订单类（Order）中的获取总价方法（getTotalPrice()），而在该方法中除了自有的一些代码逻辑外，通常需要去调用其他类的方法。比如这里调用的是用户类（User）的优惠等级方法（reductionLevel ()）和商品类（Goods）中的商品价格方法（getUnitPrice()）。很显然，优惠等级方法或商品价格方法，只要一方有错误，就会导致订单类获取总价方法的测试失败。基于这种情况，可以有两种单元测试类型。
1. 社交型单元测试（Sociable Unit Testing） 如图，测试订单类的获取总价方法（Order.getTotalPrice()）时会真实调用用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）。将被测试单元视为黑盒子，直接对其进行测试，这种单元测试称之为社交型单元测试（Sociable Unit Testing）。
2. 孤立型单元测试（Solitary Unit Testing） 如图，如果测试订单类的获取总价方法（Order.getTotalPrice()）时，使用测试替身 （test doubles） 技术来替代用户类的优惠等级方法（User.reductionLevel()）和商品类的商品单价方法（Goods.getUnitPrice()）的效果。对象及其依赖项之间的交互和协作被测试替身代替，这种单元测试称之为孤立型单元测试（Solitary Unit Testing）。
另外，上述提到的测试替身是一种在测试中使用对象代替实际对象的技术，常用的技术如下。
桩代码（Stubs）：当在对象上调用特定方法时，会对其进行硬编码（临时代码）的方式来代替真实代码提供固定响应。比如，某函数 X 的实现中调用了一个函数 Y，而 Y 不能调用，为了对函数 X 进行测试，就需要模拟一个函数 Y，那么函数 Y 的实现就是所谓的桩代码。
模拟代码（Mocks）：模拟代码跟桩代码类似，它除了代替真实代码的能力之外，更强调是否使用了特定的参数调用了特定方法，因此，这种对象成为我们测试结果的基础。
根据被测单元是否与其交互者隔离，会产生以上两种单元测试类型，这两种类型的单元测试在微服务测试中都起着重要作用，它们用来解决不同的测试问题。
可以从两个方面来保障微服务的质量：
选取合适的测试策略模型，确保测试活动全面且有效；
建立质量保障体系，使质量保障内化为企业的组织能力。
如何选择合适的测试策略模型？ 要想使面向微服务的测试活动全面且有效，可以借用“测试金字塔”的思想，针对不同类型和颗粒度的测试投入不同的精力，达到一个最佳平衡：
测试需要分层，每一层的测试颗粒度有所不同；
不同层次的测试比重有差异，通常来说，层次越高，测试比重应越少。
需要说明的是，传统意义下的测试金字塔，在微服务架构下不再完全奏效。因为微服务中最大的复杂性不在于服务本身，而在于微服务之间的交互方式，这一点值得特别注意。
因此，针对微服务架构，常见的测试策略模型有如下几种。
（1） 微服务“测试金字塔”
基于微服务架构的特点和测试金字塔的原理，Toby Clemson 有一篇关于“微服务架构下的测试策略”的文章，其中通过分析阐述了微服务架构下的通用测试策略。
如图，该策略模型依然是金字塔形状，从下到上依次为单元测试、集成测试、组件测试、端到端测试、探索式测试。
（2） 微服务“测试蜂巢”
这种策略模型是蜂巢形状，它强调重点关注服务间的集成测试，而单元测试和端到端测试的占比较少。
（3） 微服务“测试钻石”
这种策略模型是钻石形状的，组件测试和契约测试是重点，单元测试比率减少，另外增加了安全和性能等非功能的测试类型。
我想，有多少个基于微服务架构的测试团队大概就有多少个测试策略模型吧。“测试金字塔”是一种测试策略模型和抽象框架，当技术架构、系统特点、质量痛点、团队阶段不同时，每种测试的比例也不尽相同，而且最关键的，并不一定必须是金字塔结构。
理解了测试策略模型的思考框架，我们看下应如何保障测试活动的全面性和有效性。
全面性 微服务架构下，既需要保障各服务内部每个模块的完整性，又需要关注模块间、服务间的交互。只有这样才能提升测试覆盖率和全面性，因此，可以通过如下的分层测试来保证微服务的全面性。
单元测试（Unit Test） ：从服务中最小可测试单元视角验证代码行为符合预期，以便测试出方法、类级别的缺陷。
集成测试（Integration Test）：验证当前服务与外部模块之间的通信方式或者交互符合预期，以便测试出接口缺陷。
组件测试 （Component Test）：将测试范围限制在被测系统的一部分（一般是单个服务），使用测试替身（test doubles）将其与其他组件隔离，以便测试出被测代码的缺陷。
契约测试（Contracts Test）：验证当前服务与外部服务之间的交互，以表明它符合消费者服务所期望的契约。
端到端测试（End-to-end Test）：从用户视角验证整个系统的功能能否符合用户的预期。
可见，上述测试策略模型中的测试方法，是自下而上逐层扩大测试范围和边界，力保微服务架构的模块内、模块间交互、服务内、服务间交互、系统范围等维度的功能符合预期。
有效性 确定了分层测试方法，我们应该如何选取每种测试方法的比例，来确保该测试策略的有效性呢？
首先必须要明确的是不存在普适性的测试组合比例。我们都知道，测试的目的是解决企业的质量痛点、交付高质量的软件。因此不能为了测试而测试，更不能为了质量而不惜一切代价，需要考虑资源的投入产出比。
测试策略如同测试技术、技术架构一样，并不是一成不变，它会随着业务或项目所处的阶段，以及基于此的其他影响因素的变化而不断演进。但归根结底，还是要从质量保障的目标出发，制定出适合当时的测试策略，并阶段性地对策略进行评估和度量，进而不断改进和优化测试策略。因此，选取测试策略一定要基于现实情况的痛点出发，结果导向，通过调整测试策略来解决痛点。
比如，在项目早期阶段或某 MVP 项目中，业务的诉求是尽快发布到线上，对功能的质量要求不太高，但对发布的时间节点要求非常严格。那这种情况下快速地用端到端这种能模拟用户真实价值的测试方法保障项目质量也未尝不可；随着项目逐渐趋于平稳后，时间要求渐渐有了节奏，对功能的质量要求会逐渐变高，那么这时候可以再根据实际情况引入其他测试方法，如契约测试或组件测试等。
你要永远记住，适合自身项目阶段和团队的测试策略才是“完美”的策略。
如何建立质量保障体系？ 上述分层的测试策略只是尽可能地对微服务进行全面的测试，确保系统的所有层次都被覆盖到，它更多体现在测试活动本身的全面性和有效性方面。要想将质量保障内化为企业的组织能力，就需要通过技术和管理手段形成系统化、标准化和规范化的机制，这就需要建设质量保障体系。
质量保障体系：通过一定的流程规范、测试技术和方法，借助于持续集成/持续交付等技术把质量保障活动有效组合，进而形成系统化、标准化和规范化的保障体系。 同时，还需要相应的度量、运营手段以及组织能力的保障。
如下几个方面是质量保障体系的关键，后续课程也将按如下方式展开讲解。
流程规范：没有规矩不成方圆，好的流程规范是保障质量中非常关键的一环。当出现交付质量差的情况时，过程质量也一定是差的。通常会出现某些关键动作未执行或执行不到位、对事情的不当处理等情况，而这些情况可以通过建立闭环、分工明确的流程规范完全可以避免。另外，研发过程中，过程质量跟执行人的质量意识、个人能力等直接相关，那么就需要建立易执行的流程规范，降低人员的执行门槛。同时需要特别注意，规范的不断完善是几乎所有团队的常态，但当规范执行效果不好时一定要及时跟进，分析其根本原因，必要时要进行简化。
测试技术： 测试策略模型中的分层测试方法可以使面向微服务的测试活动具有一定的全面性和有效性，使得被测内容在功能方面符合预期。除功能性之外，软件质量还有其他很多属性，如可靠性、易用性、可维护性、可移植性等，而这些质量属性就需要通过各种专项测试技术来保障了。同时，还有许多测试技术的首要价值在于提升测试效率。因此合理地组合这些测试技术，形成测试技术矩阵，有利于最大化发挥它们的价值。
持续集成与持续交付：微服务的优势需要通过持续集成和持续交付的支持才能充分发挥出来，这就要求在执行测试活动时提高反馈效率、尽快发现问题。一方面要明确各种“类生产环境”在交付流程中的位置和用途差异点，保证它们的稳定可用。另一方面需要将各种测试技术和自动化技术集成起来，使代码提交后能够自动进行构建、部署和测试等操作，形成工具链，实现真正意义上的持续集成和持续交付。
度量与运营：管理学大师德鲁克曾经说过“你如果无法度量它，就无法管理它（It you can’t measure it, you can’t manage it)”。要想能有效管理和改进，就难以绕开度量这个话题。对于研发过程来说，度量无疑是比较难的，它是一个脑力密集型的过程，指标多维度，且很多维度的内容难以清晰地度量。在质量保障体系中，我将基于质量、效率、价值等多维度视角建立起基础的度量体系，并结合定期运营做定向改进，形成 PDCA 正向循环，促使各项指标稳步提升。同时，需要特别警惕的是，度量是一把双刃剑，这里我也会告诉一些我的经验教训和踩过的坑，避免走错方向。
组织保障：产品的交付离不开组织中每个参与部门成员的努力。正如质量大师戴明所说，质量是设计出来的，不是测试出来的。因此在组织中树立起“质量文化”至关重要。在这部分内容里，我将介绍常见的参与方的角色、职责和协作过程中的常见问题、对策，以及如何营造质量文化等内容。
总结 谈到了基于微服务架构下的各种质量挑战，可以从两个方面有效且高效地保障微服务的质量：确保面向微服务的测试活动具备全面性和有效性，质量保障需要内化为企业的组织能力。
端到端测试详解 定义 端到端测试（End-to-end Test）是一种用于测试整个应用程序的流程是否符合预期的测试技术。 它模拟用户真实的使用场景，通过用户界面测试应用程序，如图所示：
与其他类型的测试相反，端到端测试是面向业务的，其目的是验证应用程序系统整体上是否符合业务目标。为了实现这一目标，该系统通常被视为黑盒子：尽可能完整地部署系统中的微服务，并主要通过 GUI 和 API 等公共接口对其进行操作。
GUI：Graphical User Interface，又称图形用户界面或图形用户接口。它是采用图形方式显示的计算机操作用户界面，是一种人与计算机通信的界面显示格式，允许用户使用鼠标等输入设备操纵屏幕上的图标或菜单选项，以选择命令、调用文件、启动程序或执行其他一些日常任务。
API：Application Programming Interface，又称呼应用程序编程接口或应用程序接口。它是一组定义、程序及协议的集合，通过 API接口实现计算机软件之间的相互通信。API 的一个主要功能是提供通用功能集，同时也是一种中间件，为各种不同平台提供数据共享。
由于微服务架构包含多个具有相同行为的活动部件，因此端到端测试为服务之间传递消息的正确性提供了更多的信心，而且还可以确保正确配置了其他网络基础结构，例如防火墙、代理或负载均衡等。
测试范围 通过微服务的分层测试策略可知，端到端测试的范围比其他类型的测试大得多。
分层测试策略-测试范围
绝大多数情况下，微服务应用系统会依赖一个或多个由外部管理的微服务。通常，这些外部服务包含在端到端测试范围内。 但是，在极少数情况下，也可以主动排除它们。因为如果外部服务由第三方管理，可能会经常出现稳定性和可靠性问题，这会导致端到端测试因不可控的原因而失败。
微服务应用的典型示例 比如，某个应用程序系统依赖公安部门的背景审查服务，通过调用该服务来查询用户是否有过违法前科。首先这样的服务通常会按调用次数付费（每次 5-10 元），具有较高的测试成本，其次背景审查服务不总是稳定可用的。在这种情况下，通过服务虚拟化技术模拟背景审查服务是个不错的选择，这虽然多少会降低端到端测试的信心，但增加了测试用例套件的稳定性。
测试入口 因为端到端测试是面向业务的，那么测试时要从真实用户的使用场景来进行测试，根据应用程序系统是否有 GUI，可以分为两种情况：
应用程序系统有 GUI，这种情况下用户可以直接操作 GUI 来使用系统，那么诸如 Selenium WebDriver 之类的工具可以帮助驱动 GUI 触发系统内的特定行为。
应用程序系统没有 GUI，这种情况下，使用 HTTP 客户端通过其公共的 API 直接操作微服务。没有真实的 GUI，不能直观地看到业务功能行为，但可以通过后台数据来确定系统的正确性，比如 API 的返回结果、持久化数据的变化情况，等等。
测试设计 确定测试范围和测试入口后，可以进一步梳理出要测试的功能列表或用例集，并对其按业务能力、优先级、重要性等维度进行分组。这样可以将它们拆分为较小的任务，以便整个团队可以排序处理，比如可以首先实施优先级较高的用例组，或按紧急程度处理关键的用例，这有助于我们尽早消除潜在的障碍。
另外，由于端到端测试的目标是完全集成后的系统的行为，使得编写和维护测试用例会比其他类型的测试更加困难：
端到端测试涉及的活动部件比其他测试多得多；
端到端测试须考虑系统中的异步处理。
这些因素都可能给端到端测试带来挑战，比如测试过程不稳定、测试时间过长、测试用例集的维护成本高，等等。因此，应尽可能以最粗粒度进行端到端的测试设计。
如何开展端到端测试？ 熟悉了端到端测试的基本内容，我们来看下如何开展端到端测试，主要有如下几类：
UI 自动化
对于带有 GUI 的应用程序系统，在进行端到端测试时，可以通过 UI 自动化的方式进行。如果 GUI 是 Web 形式，则 Selenium 是首选工具；如果 GUI 是 Native 形式，则可以使用 Appium。
微博热搜榜 排名 1.中越两党两国关系新定位的深刻内涵 排名 2.1人泄露周海媚病历被行拘 排名 3.东方甄选 内讧 排名 4.以国之名悼我同胞 排名 5.来看vivo S18发布会 排名 6.杨丞琳河南风波后首现身 排名 7.红薯片真的可以拿来当被子用 排名 8.原来爱情公寓这么前卫 排名 9.女子称应聘时问过年是否放假被HR辱骂 排名 10.董宇辉 文案创作 排名 11.他竟然是真的想教会我 排名 12.为什么缝补时用针在头皮划一下 排名 13.妈妈突然的转账使我沉默了 排名 14.周海媚曾称有皱纹也可以很美 排名 15.董宇辉曾称俞敏洪给的钱挺多已够花了 排名 16.沪上阿姨 魔道祖师 排名 17.顾里三姨妈摔进蛋糕的画面有了 排名 18.很想很想你 实在不行别睡了 排名 19.盒马总部IP地址被山姆APP屏蔽 排名 20.赵一博回家 GitHub 热门榜单 排名 1:/lobehub/lobe-chat 简介: 🤖Lobe Chat-一个开源、高性能的聊天机器人框架，支持语音合成、多模式和可扩展的函数调用插件系统。支持一键免费部署您的私人ChatGPT/LLM web应用程序。 URL: https://github.com/lobehub/lobe-chat 作者: lobehub 排名 2:/HuolalaTech/page-spy-web 简介: 像chrome devtools一样远程轻松调试。 URL: https://github.com/HuolalaTech/page-spy-web 作者: HuolalaTech 排名 3:/Mintplex-Labs/anything-llm 简介: 开源ChatGPT等效于开源和闭源LLM、嵌入程序和矢量数据库的经验。在一个非常干净的UI中支持无限的文档、线程、并发用户和管理。 URL: https://github.
微博热搜榜 排名 1.习近平越南之行 排名 2.国家公祭日 排名 3.北京停课 排名 4.强信心看数据 排名 5.昨天入职今天出卖全办公室 排名 6.众星发博悼念周海媚 排名 7.朱丹公开自己以前的朋友圈 排名 8.iPhone16或调整相机岛设计 排名 9.肚子越来越小的小技巧 排名 10.北京大学回应不为专硕提供住宿 排名 11.低于这个温度一定要穿秋裤了 排名 12.周海媚去世 排名 13.再见周芷若 排名 14.周海媚生前最后一次公开亮相 排名 15.猫咪上秒舔毛下秒无症状发病去世 排名 16.周海媚曾经拒演周芷若 排名 17.创业创了一半老板去考公了 排名 18.多方回应大批空姐转行卖车 排名 19.拒绝休息羞耻 排名 20.王安宇演技 GitHub 热门榜单 排名 1:/linexjlin/GPTs 简介: 泄露的GPT提示 URL: https://github.com/linexjlin/GPTs 作者: linexjlin 排名 2:/practical-tutorials/project-based-learning 简介: 基于项目的教程策划列表 URL: https://github.com/practical-tutorials/project-based-learning 作者: practical-tutorials 排名 3:/illacloud/illa-builder 简介: 🚀Retool开源替代方案，具有低代码UI组件并支持多种数据资源。 URL: https://github.com/illacloud/illa-builder 作者: illacloud 排名 4:/mistralai/mistral-src 简介: Mistral AI 7B v0.
containerd 现在很多人说起容器都会说到docker，docker凭借镜像（images）快捷的部署，占领了极大的技术市场，docker公司将自己的核心依赖 Contanerd 捐给了 CNCF，这个就是contanerd的由来，containerd 在kubernetes在 v1.24之后的版本作为底层核心进行使用。
Containerd架构 可以看到 Containerd 仍然采用标准的 C/S 架构，服务端通过 GRPC 协议提供稳定的 API，客户端通过调用服务端的 API 进行高级的操作。 为了解耦，Containerd 将不同的职责划分给不同的组件，每个组件就相当于一个子系统（subsystem）。连接不同子系统的组件被称为模块。 总体上 Containerd 被划分为两个子系统：
Bundle : 在 Containerd 中，Bundle 包含了配置、元数据和根文件系统数据，你可以理解为容器的文件系统。而 Bundle 子系统允许用户从镜像中提取和打包 Bundles。 Runtime : Runtime 子系统用来执行 Bundles，比如创建容器。 其中，每一个子系统的行为都由一个或多个模块协作完成（架构图中的 Core 部分）。每一种类型的模块都以插件的形式集成到 Containerd 中，而且插件之间是相互依赖的。例如，上图中的每一个长虚线的方框都表示一种类型的插件，包括 Service Plugin、Metadata Plugin、GC Plugin、Runtime Plugin 等，其中 Service Plugin 又会依赖 Metadata Plugin、GC Plugin 和 Runtime Plugin。每一个小方框都表示一个细分的插件，例如 Metadata Plugin 依赖 Containers Plugin、Content Plugin 等。 总之，万物皆插件，插件就是模块，模块就是插件。
常用插件 Content Plugin : 提供对镜像中可寻址内容的访问，所有不可变的内容都被存储在这里。 Snapshot Plugin : 用来管理容器镜像的文件系统快照。镜像中的每一个 layer 都会被解压成文件系统快照，类似于 Docker 中的 graphdriver。 Metrics : 暴露各个组件的监控指标。 安装 卸载docker 首先要保证环境干净整洁，如果你有安装docker服务，需要先卸载docker，如果没有安装可以跳过
微博热搜榜 排名 1.走进敦煌共同探索那条西行路 排名 2.周海媚工作室 电话 排名 3.体脂不断下降的好习惯 排名 4.太空视角见证中国式现代化 排名 5.三星马吉拉联名款爱了 排名 6.多所高校明确不提供宿舍 排名 7.周海媚 排名 8.为什么刚起床后手握不紧 排名 9.男子拉肚子医生多问一句跑赢死神 排名 10.我是不结婚 不是不交电费 排名 11.中药只管吃不要打听 排名 12.红斑狼疮高发人群是年轻女性 排名 13.周海媚工作人员拒绝回应网传消息 排名 14.宋轶 使用小号之后会发现世界安静了 排名 15.WBG宣布TheShy离队 排名 16.薛之谦 小杨哥 排名 17.天津警方通报医院厕所发现弃婴 排名 18.游泳运动员的身材谁看了不迷糊 排名 19.88岁老太患癌医生顶压力劝手术如今快百岁 排名 20.大奉打更人 GitHub 热门榜单 排名 1:/practical-tutorials/project-based-learning 简介: 基于项目的教程策划列表 URL: https://github.com/practical-tutorials/project-based-learning 作者: practical-tutorials 排名 2:/linexjlin/GPTs 简介: 泄露的GPT提示 URL: https://github.com/linexjlin/GPTs 作者: linexjlin 排名 3:/jackfrued/Python-100-Days 简介: Python-100天从新手到大师 URL: https://github.com/jackfrued/Python-100-Days 作者: jackfrued 排名 4:/pocketbase/pocketbase 简介: 1个文件中的开源实时后端 URL: https://github.
背景 什么是 CI/CD 可观察性，我们如何为更多可观察的管道铺平道路？可观察性不仅仅是观察错误或监控基本健康信号。相反，它会更深入，以便您可以了解系统内行为背后的“原因”。
CI/CD 可观察性在其中发挥着关键作用。这是关于深入了解持续集成和部署系统的整个管道——查看每个代码签入、每个测试、每个构建和每个部署。当您组合所有这些数据时，您可以全面了解整个软件交付过程，揭示效率领域、瓶颈和潜在故障点。
CI/CD 可观察性是可观察性的一个子集，专注于软件开发生命周期。它有助于以多种方式确保流程可靠、相关且易于理解：
积极主动解决问题。没有可观察性，我们只能对问题做出反应。有了它，我们可以在问题升级之前预见并解决问题，从而节省时间和资源。 更好的决策。通过了解 CI/CD 流程的细节，团队可以在资源分配、流程变更和工具采用方面做出更明智的决策。 建立信心。通过对 CI/CD 管道的清晰洞察，开发人员、测试人员和运营团队可以对他们发布的软件更有信心。它减少了“对部署的恐惧”并培育了持续改进的文化。 问责制和透明度。可观察性确保 CI/CD 流程的每一步都是可追溯的。这意味着，如果出现问题，可以追溯到其源头，促进问责并帮助解决根本原因，而不仅仅是解决症状。 问题 CI/CD 系统并非没有自身的挑战。破坏 CI/CD 管道平稳运行的常见问题是不稳定、性能下降和配置错误。
Flakiness 片状 片状测试是 CI/CD 方程中不可预测的变量。当测试在代码没有任何更改的情况下产生不同的结果（通过或失败）时，该测试被认为是“不稳定的”。出现片状现象通常有以下几个原因：
外部依赖和环境问题。如果这些依赖项不能始终可用，则依赖于外部服务、数据库或特定环境设置的测试可能会产生不可预测的结果。如果环境设置不正确或意外拆除，也可能会发生这种情况。从本质上讲，先前测试的残留或外部服务的不可用可能会扭曲结果，使其不可靠。 比赛条件。当系统的行为依赖于不可控事件的顺序或时间时，就会出现这种情况。特别是在异步操作中，如果管理不当，事件序列的不可预测性可能会导致偶发故障。 Performance regression 性能回归 随着 CI/CD 流程的发展并变得更加复杂，系统性能可能会开始下降。这种回归可能不会立即显现出来，但长期的累积效应可能会阻碍 CI/CD 管道的效率。以下是常见的原因：
测试执行效率低下。某些测试可能会运行比必要的时间更长的时间，这可能是因为冗余操作、设置的等待时间太长或查询效率低下。这在集成和端到端测试中尤其明显。 代码和测试膨胀。当我们添加更多功能和测试而不解决技术债务或进行优化时，我们的构建时间可能会增加。有些测试从添加之日起可能会很慢。如果不解决这些问题，整个构建和测试过程可能会比需要的时间更长。 Misconfigurations 配置错误 即使是最深思熟虑的管道也可能因配置错误而失败。这可能导致：
次优测试计划。 CI/CD 管道遵循一条关键路径，其中每个步骤都依赖于前一个步骤。如果步骤未设置为按正确的顺序执行或正在等待非依赖项，则可能会导致效率低下。 次优容量规划。未配置足够的资源或对所需工作负载规划不当可能会导致管道出现瓶颈。如果 CI/CD 流程在关键阶段没有必要的能力，则可能会减慢整个工作流程或导致中断和故障。 DORA 指标 Deployment frequency 部署频率 (DF)：组织成功发布到生产环境的频率 Mean Lead time for changes 变更平均前置时间 (MLT)：从代码提交到代码在生产中运行所需的时间 Mean time to recover 平均恢复时间 (MTTR)：发生服务事件或缺陷后恢复服务需要多长时间 Change failure rate 变更失败率 (CFR)：导致失败的变更百分比 优化 CI/CD 可观察性 目前GraCIe 是 Grafana 正在使用的应用程序插件，旨在为用户提供一种简单的方法来了解他们的 CI/CD 系统。它非常适合评估构建性能、识别测试结果中的不一致以及分析构建输出。该应用程序简化了这些流程，旨在轻松提供有关管道的见解。
