风帕克风机有限公司

风帕克风机;透浦式鼓风机;台湾中压风机;环保处理;粉尘处理机...
93

VIP会员

风帕克风机有限公司

张云蕾 (先生)

经营模式: 生产型

主营业务: 风帕克风机;透浦式鼓

所在地区: 上海市-松江区-九亭镇

已认证:    

收藏店铺
网站公告
风帕克风机有限公司(上海利楷机电设备有限公司)专业从事高科技的各种工业鼓风机与减速机的销售。近年来肩负着顾客们对产品质量与价格的追求,实现效率的最大化和提供广泛的技术资源等方面做着不懈的努力。 公司奉行品质第一、顾客满意的经营理念,不断吸纳专业人才,使得公司始终拥有一批掌握业界高端技术的科技人才。公司以积极务实的作风,借鉴各种先进的管理经验,不断引进国外先进设备实现自我完善,建立起良好的企业文化。目前产品有两大系列,风帕克风机系列有2HB高压鼓风机系列,4HB高压鼓风机系列,CX透浦式鼓风机系列,TB透浦式鼓风机系列,HTB透浦式鼓风机系列,FAB/FABR 斜齿系列、FAD/FADR中空斜齿系列、FABZ 直齿系列、FPG/FPGA 直齿系列等。客户的服务和技术选型,同时在上海有大量的库存备货来满足市场的需求, 配备选型工程师数名,
产品分类
联系方式
友情链接
正文
百度APP移动研发平台及DevOps实践
发布时间:2021-11-24

  百度APP从2018年开始,团队规模和业务规模都迎来了巨大的增长,也带来了研发效率、组件复用、APP性能等多个目标的挑战,于是驱使我们做了很多组件化的工作。随着百度APP组件化程度的提高,组件逐步拆解到各个独立仓库,组件真正做到了逻辑、资源各有归属,主工程也实现了完全壳化,于是我们开始建设工具链(MGIT、EasyBox)来规范组件管理与使用并提升编译速度。工具链更多承担的是开发环境的配置,提升的是研发同学在开发阶段的效率,但面临整体移动研发流程琐碎,多仓库环境下的持续集成困难,组件质量难以保障等问题,我们仅仅依靠工具链是不够的,于是Tekes应运而生。

  Tekes 是服务百度移动研发的一站式服务平台,目前主要包括三个大的功能:

  Tekes 的名称起源于新疆的特克斯县(Tekes County)。特克斯县因八卦布局而闻名,是国内唯一没有红绿灯的城市,城内路路相通、街街相连,传说从来不堵车。我们借此寓意,目标提升超级App及孵化产品全流程研发效率。

  目前 Tekes 管理着包括百度APP在内的6条产品线,Android及iOS双端超过800+个仓库,1500+个组件,平均每天触发自动化研发流程相关的流水线+次。

  接入 Tekes 后,移动端开发同学不仅可以通过自动化研发流程大幅缩短开发时间,还可以通过研发各阶段流水线产出的质量报告、前端页面展示的产品线和组件的防控劣化数据来改进开发流程,提升质量意识。

  百度APP不同发展阶段有着不同的目标,但始终对研发效率有着刚性需求,Tekes 也在不断强化自身的架构来支撑研发全流程高速运转,并逐步发展为现在的『百度移动研发的一站式服务平台』。发展阶段如下图所示:

  Tekes 一开始是作为组件二进制自动发布准入的调度后台服务,这是一套基于代码组合入(Topic Merge)和流水线持续集成(CI)的自动化流程。

  组合入是将一组(一个或多个)仓库的代码同时进行合入操作。由于百度APP的客户端代码是多仓库的,开发者在开发过程中不可避免地需要同时修改多个组件,此时由于代码入库的时机不同,导致入库中间过程中持续集成触发打包会常常发生错误,因此我们引入组合入的概念。

  当 Tekes 收到代码组合入通知时,会主动触发一条百度APP持续集成流水线,称为『发布流水线』,这条流水线会使用 EasyBox 等工具构建百度APP工程、编译有代码修改的组件并发布到组件的二进制仓库。整个过程称为『发布流程』。

  Tekes收到组件发布完成的通知后,会自动修改主工程的配置文件,将APP引用组件的版本自增。整个过程称为『准入流程』。

  主工程,即所谓的“壳工程”,顾名思义就是客户端工程分离业务代码,仅仅保留一些工程配置选项和组件描述文件得到的”空壳”。构建完整的APP工程时,会将业务代码以组件的形式集成进来的。

  这个阶段,Tekes的角色是一个调度者和连接者,本身没有什么架构可言。通过调度CI 流水线,连接 EasyBox 工具链和 百度APP,实现了在研发流程集成测试阶段将组件从源码形态自动发布为二进制形态,并实现自动化准入。

  组件二进制自动发布准入将每个开发人员的上车耗时从小时级别降低到分钟级别,不仅节约了宝贵的时间,还有效地降低了版本迭代 delay 的风险。

  2019年百度APP中台化如火如荼,随着中台化的工作不断推进,不仅需要有业务中台提供成熟的组件支持快速组装APP,还需要技术中台来赋能APP自动化能力,提高流程运转效率,保障业务的连续性。

  Tekes 作为技术中台的核心能力之一,也在积极探索如何升级移动端研发模式,具体工作概括成”三板斧”。

  完善自动化研发流程,分为横向和纵向两部分工作。横向上,扩展更多自动化流程来替代以前手动或者半手动的流水线工作,例如打包、单测、体积检查、infer等;纵向上,在已有的流水线上增加更多的规范化约束,例如发布流程的版本号规范检查、接口/依赖的劣化审核等,准入流程的APP体积控制等。

  从 Tekes 独立出了一个”移动组件管理平台”来专门管理可复用的组件为中台化服务,完成整个组件(及SDK)发布及准入的闭环,如下图所示:

  移动组件管理平台负责展示组件的数据(详情、组件化信息及质量报告),它的数据来源于 Tekes 的组件自动发布、组件手动发布或者 SDK/开源库组件的手动上传,产品线的中台负责人可以通过页面交互触发 Tekes 的组件自动准入 将指定组件的指定版本准入到APP中。

  上游和”APP中心”(百度内部的APP开发平台)互通,下游和矩阵产品团队进行接洽和工程改造。矩阵产品通过接入 Tekes 的自动化流程和组件防控劣化,解决其手动发布组件成本高,源码仓库编译效率低,组件的质量难以控制等问题。

  这个阶段对 Tekes 进行了平台化的升级,明确了 Tekes 的三大服务——流程、组件和产品线,整个架构如下图所示:

  2021年伊始,DevOps 作为软件开发领域热门的概念之一,并已成为敏捷软件文化的一部分。为了更好地提升百度APP及矩阵产品的工程能力和研发效率,实现”快速交付价值,灵活响应变化”。Tekes 也结合自身的现状积极探索移动 DevOps。

  DevOps 是人员、流程和技术的联合,以不断向客户提供价值为目标,使以前孤立的角色(开发、IT 运营、质量工程和安全)可以协调和协作,以生产更好、更可靠的产品。——Azure DevOps

  在研发流程中,价值流可以定义为从需求提出到最终转化成产品,交付价值给用户的过程。

  百度的研发流程,大致可以分为需求、 开发、测试、集成和交付五个阶段,我们以此建立从左到右平滑的价值流,并梳理了每个阶段的主要活动,这些主要活动有些是手动的,有些是自动的(依赖我们建设好的CI/CD流水线),如下图所示:

  最后,在部门内同步DevOps认知和目标,发扬乐于协作积极沟通的文化,不拘泥于优化局部指标,而是把局部经验转化成全局经验,建立起全局知识库。

  移动 DevOps 是 Tekes 当前所处的阶段,还在不断改善中,架构如下图所示:

  Tekes 平台:移动研发平台,面向移动研发团队的PMO、开发、测试、运维人员

  上游服务:依赖其他平台提供的服务,例如UUAP、iCode、iCafe、iPipe等

  百度云服务:容器云平台,提供必要的基础设施和中间件,例如数据库、消息队列、对象存储等

  全局知识库:除了平台功能之外,服务号、文档中心及相关系统,帮助提升移动研发团队工程能力,构建更优秀的APP

  相较于上个阶段的架构,这个阶段最显著变化是将流程服务升级成 DevOps 服务并建设了全局知识库,具体工作我们已经介绍过了。然而我们的工作不止于此,随着 Tekes 平台的壮大,越来越多的产品线接入到了 Tekes 中,我们一方面重构了 Tekes 后端服务的架构,拆分微服务,积极拥抱云原生来提升整体的扩展性和稳定性,更好地为多产品线服务;另一方面,我们也尝试把 Tekes 在 百度APP 的 DevOps 实践转化成经验并落地到其他产品线上,这是一个长期探索的过程,我们需要看的更远。

  业务流程需要编排自身的流程定义,流程定义是一种描述流程图的 DSL,我们有一套自己的流程定义的语法,解释起来会比较麻烦,所以我们直接用流程图代替,例如:

  业务流程将流程定义注册给工作流服务,工作流服务管理了所有流程实例的生命周期,业务流程不用关心具体流程是如何执行和调度的,只需要在监听方法里面写自己的业务逻辑,实现了业务与流程之间的解耦。

  CI/CD服务接收来自流水线的消息,并将其包装成”事件”,”事件”经过”过滤器”过滤后最终传递给工作流服务进行处理。

  流水线通过事件和工作流服务建立联系。事件有三种类型,都直接或间接来自于流水线的通知,如下图:

  变更事件(Change Event)。 仓库代码change合入前流水线(Change流水线)的消息,包含一些基本的变更信息;

  合入事件(Merge Event)。 仓库代码change合入后流水线的消息,除了一些基本的变更信息外,还有评审人合入人的信息;

  基础扩展事件,目前的扩展事件都是经过合入事件特殊处理而来的。各个基础扩展事件彼此独立,但是和合入事件并存

  新提 交事件(NewCommit Event)。 来自仓库拉出新分支第一次提交的消息。 因为这种提交会跳过评审直接合入,所以单独处理;

  组合入事件(TopicMerge Event)。 同一个topic下的仓库change全部合入后的消息,包含一个或多个合入事件。 组合入事件是启动 提测/发布 流程的事件源;

  Tekes合入事件(TekesMerge Event)。 Tekes自动流程生成的change(通常是自动准入)合入后的消息。 因为这种提交会触发Tekes的自动评审和合入,所以也单独处理 。

  自定义事件,这是最多的事件,当CI流水线执行一个业务流程时,完成每一项任务(例如组件化检查)都会请求一次Tekes,会生成对应的事件,可以说自定义事件是推进流程的事件源。

  CI/CD服务处理事件时会有若干个过滤器,这里的过滤器基于责任链模式串联起来,形成一条过滤链。事件在链上传递,每一个过滤器都有机会处理该事件,并在处理后选择拦截或继续传递。

  责任链模式在面向对象程式设计里是一种软件设计模式,它包含了一些命令对象和一系列的处理对象。每一个处理对象决定它能处理哪些命令对象,它也知道如何将它不能处理的命令对象传递给该链中的下一个处理对象。该模式还描述了往该处理链的末尾添加新的处理对象的方法。

  我们介绍事件时说到 组合入事件是启动 提测/发布 流程的事件源,我们就以他为例,介绍一下他连接的过滤器:

  TekesIgnoreFilter: 判断 Tekes 是否处理这个事件,例如 Tekes关闭了自身 DevOps服务 或者 此次提交的change信息命中了 Ignore 的逻辑(例如仓库、提交人,commit log关键字);

  TopicMergeValidator: 校验组合入是否有效,因为获取组合入的信息需要依赖上游服务(iCode),我们会 在 这里重新请求一次确保当前topic下的所有提交都已合入并能和 TopicMerge Event 包含的所有Merge Event一一对应;

  MatchAppJudge: 裁决 TopicMerge 匹配的产品线(实际上是产品线的主工程),如果裁决不出来则返回失败。 因为 TopicMerge 只有一组仓库合入的信息,没有产品线的信息,而后续如果触发流程,需要基于一个产品线的主工程去构建、编译及打包。 由于存在多个产品线复用组件(仓库)的情况,我们裁决产品线有一套比较复杂的判断逻辑,这里也不做详细介绍。

  工作流(Workflow),是对工作流程及其各操作步骤之间业务规则的抽象、概括描述。工作流建模,即将工作流程中的工作如何前后组织在一起的逻辑和规则,在计算机中以恰当的模型表达并对其实施计算。工作流要解决的主要问题是:为实现某个业务目标,利用计算机在多个参与者之间按某种预定规则自动传递文档、信息或者任务。

  工作流引擎是驱动工作流的工程实现,负责解释流程定义、管理流程数据、控制流程运行,并和业务解耦。我们的工作流服务就是对工作流引擎的封装。

  流程控制服务适配器。流程控制服务(工作流引擎)的适配器,封装了流程部署、流程启动、流程停止及流程推进等多个接口的调用。适配器的好处是方便替换依赖的工作流引擎;

  流程执行器。 事件最后的处理器,通过解析事件获取参数,进一步调用适配器启动流程或推进流程的方法;

  流程注册中心。 注册业务流程的流程定义和资源,流程注册会进一步调用适配器流程部署的方法,资源注册则会将业务流程的回调方法保存到注册表中;

  流程调度器。 监听运行中的流程,会根据注册表的信息,将对应流程或阶段的回调消息分发给业务流程

  无论是移动研发效能提升还是DevOps实践,都没有银弹。不同的企业之间、部门之间和产品之间都存在着差异,很难有一个通用的平台或工具去适配所有场景、解决所有问题。

  而 Tekes 做的,就是从百度APP出发,在不同阶段不同目标下,做到最好的提升移动研发效能的解决方案。通过建设平台和开发工作流,制定规范和输出文化,让百度移动研发团队的移动开发同学能够专注于交付价值,最终我们也能成为整个百度APP移动研发价值的一部分。

  最近有一些小伙伴,让我帮忙找一些 面试题 资料,于是我翻遍了收藏的 5T 资料后,汇总整理出来,可以说是程序员面试必备!所有资料都整理到网盘了,欢迎下载!