潍坊制作网站,怎样在在农行网站上做风险评估,php是世界上最好的语言,wordpress 不同域名目录 一、引言 二、服务拆分的原则 三、Bidding服务拆分的设计 四、Bidding拆分的节奏和目标收益 1.Bidding拆分目标 2.预期的拆分收益 五、测试计划设计 六、各流量类型灰度切量方案 七、结语 一、引言 代码越写越多怎么办#xff1f;在线等挺急的#xff01;Bi…目录一、引言二、服务拆分的原则三、Bidding服务拆分的设计四、Bidding拆分的节奏和目标收益1.Bidding拆分目标2.预期的拆分收益五、测试计划设计六、各流量类型灰度切量方案七、结语一、引言代码越写越多怎么办在线等挺急的Bidding-interface服务代码库代码量已经达到100w行Bidding-interface应用是出价域核心应用之一主要面向B端商家。跟商家后台有关的出价功能都围绕其展开。是目前出价域代码量最多的服务。随着出价业务最近几年来的快速发展出价服务承接的流量虽然都是围绕卖家出价但是已远远超过卖家出价功能范围。业务的快速迭代而频繁变更给出价核心链路高可用、高性能都带来了巨大的风险。经总结有如下几个痛点核心出价链路未隔离出价链路各子业务模块间代码有不同程度的耦合迭代开发可扩展性差往往会侵入到出价主流程代码的改动。每个子模块缺乏独立的封装而且存在大量重复的代码每次业务规则调整需要改动多处容易出现漏改漏测的问题。大单体功能模块定义混乱历史原因上层业务层代码缺乏抽象代码无法实现复用需求开发代码量大导致需求估时偏高经常出现20人日的大需求需求开发中又写出大量重复代码导致出价服务代码库快速膨胀应用启动耗时过长恶性循环。B/C端链路未隔离B端卖家出价链路流量与C端价格业务场景链路流量没有完全隔离由于历史原因有些B端出价链路接口代码还存在于price应用中偶尔B端需求开发会对C端应用做代码变更。存在一定的代码管控和应用权限管控成本。发布效率影响代码量庞大导致编译速度缓慢。代码过多类的依赖关系更为复杂持续迭代逐步加大编译成本随着持续迭代新的代码逻辑 引入更多jar 依赖间接导致项目部署时长变长蓝绿发布和紧急问题处理时长显著增加同时由于编译与部署时间长直接影响开发人员在日常迭代中的效率自测debug部署。业务抽象分层不合理历史原因出价基础能力领域不明确出价底层和业务层分层模糊业务层代码和出价底层代码耦合严重出价底层能力缺乏抽象上层业务扩展需求频繁改动出价底层能力代码。给出价核心链路代码质量把控带来较高的成本 每次上线变更也带来一定的风险。以上对于Bidding服务的拆分和治理已经箭在弦上不得不发。否则持续的迭代会继续恶化服务的上述问题。经过前期慎重的筹备设计排期拆分和测试。目前Bidding应用经过四期的拆分节奏已经马上要接近尾声了。服务被拆分成三个全新的应用目前在小流量灰度放量中。本次拆分涉及1000Dubbo接口300个HTTP接口200 MQ消息100个TOC任务10个 DJob任务。本人是出价域测试一枚参与了一期-四期的拆分测试工作。项目在全组研发测试的ALL IN投入下已接近尾声。值此之际输出一篇文章从测试视角复盘下Bidding服务的拆分与治理也全过程揭秘下出价域内的拆分测试过程。二、服务拆分的原则首先在细节性介绍Bidding拆分之前。先过大概过一下服务拆分原则单一职责原则 (SRP)每个服务应该只负责一项特定的业务功能避免功能混杂。高内聚、低耦合服务内部高度内聚服务之间松耦合尽量减少服务之间的依赖关系。业务能力导向根据业务领域和功能边界进行服务拆分确保每个服务都代表一个完整的业务能力。拆分原则之下还有不同的策略可以采纳基于业务能力拆分、基于领域驱动设计 (DDD) 拆分、基于数据拆分等等。同时拆分时应该注意避免过度拆分、考虑服务之间的通信成本、设计合理的 API 接口。服务拆分是微服务架构设计的关键步骤需要根据具体的业务场景和团队情况进行综合考虑。合理的服务拆分可以提高系统的灵活性、可扩展性和可维护性而不合理的服务拆分则会带来一系列问题。三、Bidding服务拆分的设计如引言介绍过。Bidding服务被拆分出三个新的应用同时保留bidding应用本身。目前共拆分成四个应用Bidding-foundtionBidding-interfaceBidding-operation和Bidding-biz。详情如下出价基础服务-Bidding-foundation出价基础服务对出价基础能力抽象出价领域能力封装基础能力沉淀。出价服务-Bidding-interfaces商家端出价提供出价基础能力和出价工具提供商家在各端出价链路能力重点保障商家出价基础功能和出价体验。出价运营服务-Bidding-operation出价运营重点支撑运营对出价业务相关规则的维护以及平台其他域业务变更对出价域数据变更的业务处理出价管理相关配置出价规则配置、指定卖家规则管理、出价应急隐藏/下线管理工具等业务大任务包括控价生效/失效商研鉴别能力变更商家直发资质变更品牌方出价资质变更等大任务执行。业务扩展服务-Bidding-biz更多业务场景扩展侧重业务场景的灵活扩展可拆出的现有业务范围国补采购单出价空中成单业务活动出价直播出价现订现采业务预约抢购新品上线预出价入仓预出价。应用拆分前后流量分布情况四、Bidding拆分的节奏和目标收益服务拆分是项大工程对目前的线上质量存在极大的挑战。合理的排期和拆分计划是重点可预期的收益目标是灵魂。经过前期充分调研和规划。Bidding拆分被分成了四期每期推进一个新应用。并按如下六大步进行Bidding拆分目标解决Bidding大单体问题对Bidding应用进行合理规划完成代码和应用拆分解决一直以来Bidding大单体提供的服务多而混乱维护成本高应用编译部署慢发布效率低等等问题。核心链路隔离提升稳定性明确出价基础能力对出价基础能力下沉出价基础能力代码拆分出独立的代码库并且部署在独立的新应用中实现出价核心链路隔离提升出价核心链路稳定性。提升迭代需求开发效率完成业务层代码抽象业务层做组件化配置化实现业务层抽象复用降低版本迭代需求开发成本。实现出价业务应用合理规划各服务定位、职能明确分层抽象合理更好服务于企/个商家、不同业务线运营等不同角色业务推进。预期的拆分收益出价服务应用结构优化完成对Bidding大单体应用合理规划拆分向下沉淀出出价基础服务应用层降低出价基础能力维护成功向上抽离出业务扩展应用层能够实现上层业务的灵活扩展同时把面向平台运营和面向卖家出价的能力独立维护在代码库和应用层面隔离有效减少版本迭代业务需求开发变更对应用的影响面降低应用和代码库的维护成本。完成业务层整体设计业务层抽象复用业务层做组件化配置化提升版本迭代需求开发效率降低版本迭代需求开发成本按业务类型对业务代码进行分类统一设计方案提高代码复用性支持业务场景变化时快速扩展以引导降价为例当有类似降价换流量/降价换销量新的降价场景需求时可以快速上线类似情况每个需求可以减少10-20人日开发工作量。代码质量提升 通过拆分出价基础服务和对出价流程代码做重构将出价基础底层能力代码与上层业务层代码解耦降低代码复杂度降低代码冲突和维护难度从而提高整体代码质量和可维护性。开发效率提升 缩短应用部署时间治理后的出价服务将加快编译和部署速度缩短Bidding-interfaces应用发布(编译部署)时间 由12分钟降低到6分钟从而显著提升开发人员的工作效率减少自测、调试和部署所需的时间。以Bidding服务T1环境目前一个月编译部署至少1500次计算每个月可以节约150h应用发布时间。提升问题定位效率出价基础服务层与上层业务逻辑层代码库应用分开后排查定位开发过程中遇到的问题和线上问题时可以有效缩小代码范围快速定位问题代码位置。五、测试计划设计服务拆分的前期研发团队投入了大量的心血。现在代码终于提测了进入我们的测试环节为了能收获更好的质量效果同时也为了不同研发、测试同学的分工。我们需要细化到最细粒度即接口维度整理出一份详细的文档。基于此文档的基础我们确定工作量和人员排期如本迭代我们投入4位研发同学2位测试同学。完成该200个Dubbo接口和100个HTTP接口以及20个Topic迁移。对应的提测接口标记上负责的研发、测试、测试进度、接口详细信息等内容。基于该文档的基础上我们的工作清晰而明确。一个大型的服务拆分也变成了一步一步的里程碑任务。接下来给大家看一下关于Bidding拆分。我们团队整体的测试计划我们一共设计了五道流程。第一关自测接口对比每批次拆分接口提测前研发同学必须完成接口自测。基于新旧接口返回结果对比验证。验证通过后标记在文档中再进入测试流程。对于拆分项目自测卡的相对更加严格。由于仅做接口迁移逻辑无变更自测也更加容易开展。由研发同学做好接口自测可以避免提测后新接口不通的低级问题。提高项目进度。在这个环节中。偶尔遇见自测不充分、新接口参数传丢、新Topic未配置等问题。三期、四期测试中我们加强了对研发自测的要求。第二关测试功能回归这一步骤基本属于测试的人工验证同时重点需关注写接口数据验证。回归时要测的细致。每个接口测试同学进行合理评估。尽量针对接口主流程进行细致功能回归。由于迁移的接口数量多历史逻辑重。一方面在接口测试任务分配时要尽量选择对该业务熟悉的同学。另一方面承接的同学也有做好历史逻辑梳理。尽量不要产生漏测造成的问题。该步骤测出的问题五花八门。另外由于Bidding拆分成多个新服务。两个新服务经常彼此间调用会出现问题。比如二期Bidding-foundation迁移完成后Bidding-operation的接口在迁移时依赖接口需要从Bidding替换成foundation的接口。灰度打开情况下调用新接口报错仍然走老逻辑。测试时需要关注trace中是否走了新应用。第三关自动化用例出价域内沉淀了比较完善的接口自动化用例。在人工测试时测试同学可以借助自动化能力完成对迁移接口的回归功能验证。同时在发布前天组内会特地多跑一轮全量自动化。一次是迁移接口开关全部打开一次是迁移接口开关全部关闭即正常的自动化回归。然后全员进行排错。全量的自动化用例执行对迁移接口问题拦截有比较好的效果。因为会有一些功能点人工测试时关联功能未考虑到但在接口自动化覆盖下无所遁形。第四关流量回放在拆分接口开关打开的情况下在预发环境进行流量回放。线上录制流量的数据往往更加复杂经常会测出一些意料之外的问题。迭代过程中我们组内仍然会在沿用两次回放。迁移接口开关打开后回放一次开关关闭后回放一次。跟发布配置保持一致。第五关灰度过程中关闭接口开关功能回滚为保证线上生产质量在迁移接口小流量灰度过程中。我们持续监测线上问题告警群。以上就是出价域测试团队针对服务拆分的测试流程。同时遵循可回滚的发布标准拆分接口做了非常完善的灰度功能。下一段落进行介绍。六、各流量类型灰度切量方案出价流程切新应用灰度控制从几个维度控制总开关出价类型范围channel范围source范围bidSource范围uid白名单uid百分比(0-10000)灰度策略支持 接口维度 按照百分比进行灰度切流支持一键回切Dubbo接口、HTTP接口、TOC任务迁移、DMQ消息迁移分别配有不同的灰度策略。七、结语拆分的过程中伴随着很多迭代需求的开发。为了提高迁移效率我们会在需求排期后并行处理迭代功能相关的接口把服务拆分和迭代需求一起完成掉。目前我们的拆分已经进入尾声。迭代发布后整体的技术项目就结束了。灰度节奏在按预期节奏进行~值得一提的是目前我们的流量迁移仍处于第一阶段即拆分应用出价域内灰度迁移上游不感知。目前所有的流量仍然通过bidding服务接口进行转发。后续第二阶段灰度验证完成后需要进行上游接口替换流量直接请求拆分后的应用。https://mp.weixin.qq.com/s/MAtpi-s4iTs4VjeDyzxCCA