携程网站建设项目seo深圳优化

携程网站建设项目,seo深圳优化,如何做网站视频,建设行业协会网站发展的建议前言 从3月中旬到前几天#xff0c;我的工作重心一直在符号还原服务的重构上#xff1b;整个重构从提案、方案设计#xff0c;到难点攻关、核心功能实现#xff0c;最后到功能验证#xff0c;性能优化以及搭建监控和压力测试。全程的体验可以说是历尽艰险#xff0c;但也…前言从3月中旬到前几天我的工作重心一直在符号还原服务的重构上整个重构从提案、方案设计到难点攻关、核心功能实现最后到功能验证性能优化以及搭建监控和压力测试。全程的体验可以说是历尽艰险但也成就感满满符号还原系统的开发告一段落这里我就遵循空雨伞的思考方式来总结下整个重构工作需要了解的词symbol demangle在swift, C, Rust等语言中为了唯一标识变量/类/方法等程序实体编译器以函数、结构、类或其他数据类型的名称对附加信息进行编码以便将更多语义信息从编译器传递到链接器如不同包中的同名方法等符号还原根据平台的不同程序的运行时堆栈中可能充满了内存地址或混淆后的函数名这样的堆栈是无法阅读的。而符号还原则是将它们转换为人类可读的类名/方法名、文件名和行号的过程。本文中的符号还原泛指iOS、Java Native等内存地址形的符号还原以及Android, javascript等混淆形的符号还原。在iOS开发中使用混淆工具如IpaGuard可以对IPA文件进行代码和资源混淆增加反编译难度而符号还原则用于调试和崩溃分析时的逆向处理。Android 混淆堆栈Caused by: java.lang.Exception: Exception at the end of the callat ly.count.android.demo.a.b(SourceFile:29)at ly.count.android.demo.a.a(SourceFile:21)at ly.count.android.demo.ActivityExampleCrashReporting.c(SourceFile:98)at ly.count.android.demo.ActivityExampleCrashReporting.b(SourceFile:94)at ly.count.android.demo.ActivityExampleCrashReporting.a(SourceFile:90)at ly.count.android.demo.ActivityExampleCrashReporting.onClickCrashReporting10(SourceFile:82)Android 符号还原后堆栈Caused by: java.lang.Exception: Exception at the end of the callat ly.count.android.demo.Utility.void DeepCall_b()(SourceFile:29)at ly.count.android.demo.Utility.void DeepCall_a()(SourceFile:21)at ly.count.android.demo.ActivityExampleCrashReporting.void deepFunctionCall_3()(SourceFile:98)at ly.count.android.demo.ActivityExampleCrashReporting.void deepFunctionCall_2()(SourceFile:94)at ly.count.android.demo.ActivityExampleCrashReporting.void deepFunctionCall_1()(SourceFile:90)at ly.count.android.demo.ActivityExampleCrashReporting.void onClickCrashReporting10(android.view.View)(SourceFile:82)事实项目中的老翻译服务的呈现形式为分端实现各端分别部署微服务提供翻译服务consumer, web这造成了很多额外的 运维 成本和维护成本实际上大部分的翻译层逻辑是相同的核心逻辑都是地址 / 混淆后符号到符号的映射在redis缓存符号表管理以及符号表监控等方面也都可以使用统一的架构和解决方案。在这些前提下统一的符号还原模块成为了可能思路实现符号还原大一统的大前提是统一各端符号表要实现各端形式各异的符号表到统一格式的能实现高效率翻译的符号表的转换统一符号表格式后则要考虑符号表的管理在历史各端符号还原服务的生命历程中有不少的问题都是符号表管理不当导致的排查起来也相当痛苦。在统一的符号还原服务中符号表的管理粒度依旧为产品 → 版本号 → 符号表但需要依据MECE原则设计完整的符号表生命周期保证整个符号表系统的可控性和可维护性其次是符号表缓存结构设计通过redis缓存减少实际高并发翻译中与符号表的文件IO减轻 服务器 压力的同时增加整个翻译服务的吞吐量在符号表的相关难点攻克后我们才能开始真正的符号翻译整个翻译流程需要保证架构和实现的健壮性高性能可维护性以支持实际翻译服务中的各种需求最后是监控方案的设计与实现首先要基设计翻译服务的SLI以及SLO再基于翻译流程接口以及符号表生命周期进行监控埋点完成翻译层监控Dashboard的配置行动思路清晰开始行动技术攻坚首先要解决我们统一符号还原的大前提——将各端的符号表转换为统一格式的符号表各端的符号表基本可以分为内存地址形和混淆形符号表本质都是映射关系内存地址 - 符号 / 混淆符号 - 原始符号那么要统一这两类符号表我们的思路就是将混淆类的混淆符号首先转换为数字这里就要面对两个问题散列哈希算法的选择满足字符串 → 数字且散列效果较好面对 Android 符号表 / js 符号表这类有多层结构的符号表时如何在压平结构后保证最终的结果不溢出经过多次技术评审后最终我们攻克了这里的技术难关完成了符号表统一在后续的过程中面临的架构设计、监控埋点等一系列其它难题时团队内也是不断通过技术评审集思广益解决关键问题的同时保证信息差最小一一攻克难关。对于iOS应用混淆工具如IpaGuard可以提供代码和资源混淆增加应用安全性而符号还原服务则需处理混淆后的符号以支持调试。稳步开发在主要的技术难点都基本确定了解决方案后我们开始了正式的统一符号还原模块的开发。基于已经设计好的满足 golang 标准项目结构的包结构设计逐个完成各核心 package 的开发(symbolmap, transform, translate等)以及 library 内部分基础组建的更新(kafka, redis分布式锁, resource等)并编写完善的单元测试。在完成符号还原模块的主体部分后迅速开始交叉测试工作最终在3个星期内完成了符号还原模块本身的交付进度推进在符号还原模块开发的过程中受到了整个项目大版本交付进度的催促而在符号还原模块这个开发阶段大家都还沉浸在性能优化与监控完善方面的工作中有些忽略了整体进度后续也是及时将数据流验证提到最高优先级在较短的时间内完成了各数据流的验证交付项目后再捡起符号还原模块本身的性能优化和监控系统完善的工作继续完成了大文件符号表转换的性能优化符号表管理api接口拓展部分架构调整以及监控指标建设等工作测试收尾在最终的符号还原模块交付前我们继续做了 私有云 环境的适配工作以及整个符号还原模块的系统测试和压力测试同时验证监控面板、监控指标的有效性。在不间断的测试过程中也发现了符号还原服务接入的部分数据流上的适配问题以及在kafka版本上的适配问题等关键问题完成了及时的修复同时也不断迭代优化项目内的符号表生命周期、翻译流程等完善监控面板保证一眼就能抓住关键信息。总结重新以空雨伞的视角审视这次的符号还原服务重构工作less well 如下less后期的进度把控以及测试工作上还有待改进进度把控上没有把握好优先级过度沉浸在了项目开发工作本身而忽略了交付进度虽然在前期完成了大量单元测试的编写保证了核心 package 的可用性但在环境适配、组件测试以及数据流接入测试等方面没有以较高的优先级做好、well前期的工作动机、思路整理和核心开发工作都差强人意整体的重构思路完整清晰遵循MECE原则保证重构工作完整可控技术难点的攻克上坚持了技术评审保证信息透明集思广益在完成准备工作后快速完成了核心代码的开发为后续的一系列监控和测试工作留足了时间