黄全：荔枝架构实践与演进历程

　　2、在高并发环境下，Mysql 查询性能成为瓶颈。当数据量呈现爆发式增长，Mysql 查询速度变慢。我们对分布式数据库中间件作了扩展，在操作mysql时，在数据库上层加入缓存memcached后，大大提高了查询性能,并且自动维护缓存和数据库数据的一致性。

　　3、访问量上涨，受日志文件的IO影响，服务出现长GC(stop the world，阻塞业务线程)。类似服务出现长GC的问题，很多互联网公司都会遇到。在GC的整个回收过程中，会有两个步骤涉及到IO操作。第一个操作就是写 perf 文件;第二个是写 gc log的时候。一台服务器一般会部署多个服务，这些服务在运行的过程中，会不断输出日志，这时容易出现与其他服务的GC线程发生抢占IO资源的冲突，而导致GC线程阻塞等待，最终导致整个GC过程耗时较长，影响了服务的响应和稳定。为了解决这些问题，采取了两个方案来解决：第一，不生成 perf 文件，在服务启动脚本里，加上参数 -XX:+PerfDisableSharedMem就可以了;第二，将 GC日志保存到内存盘中( tmpfs 或 ramfs )，在服务启动脚本里加上 -Xloggc:/dev/shm/lz-app-gc.log参数就可以解决了。

　　4、随着业务的发展，系统的整体访问量越来越大，后端服务接口调用耗时越来越长，导致经常超时。经过分析和统计发现，整个平台实际上以“读多写少”的场景居多。有没有一个兼顾全局的解决方案呢?在分布式服务框架中开发“缓存接口”功能，解决了这个问题。其实有很多场景，我们是不需要实时看到最新数据的，即使新数据晚了30秒或者1分钟用户才看到，也是可以接受的。

　　5、系统间异步消息通知功能不完善。之前，是通过redis来做异步消息通知，好处是比较轻量化，但是随着数据量增加，大数据传输增多，出现多个消费方需要消费相同消息的时候，redis 就不是很适用了。这时，使用 kafka可以满足系统间消息通知、大数据量传输、多个消费者消费相同消息的场景。

　　6、当服务框架中的各种功能都比较完善后，却发现缺少一个报警功能。比如在请求失败/超时/异常等，如果有监控机制，就可以找到具体的问题点。借助监控系统，我们可以看到服务器负载、物理内存、swap、磁盘等信息，也能监控到GC信息的回收时间、次数以及JVM堆信息等，还可以对异常请求进行统计。

　　7、随着服务的增多，每个服务都有很多实例，导致整个架构的调用链路不清晰，也不能预知整体架构存在的瓶颈。引入skywalking 实现调用链跟踪功能后，能快速定位到线上故障和整个架构的性能瓶颈。

　　8、主要是更新服务的问题，上线/重启服务操作很原始，之前都是人工在本地打包，再上传到服务器。服务不多的时候还能支撑，但是服务实例数量开始增多的情况下，这种方式就需要改进。荔枝的做法是开发一个自动发布平台，一键式操作。另外，就是通过jenkins + gitlab，接入自动发布平台，实现自动打包、一键发布。

　　9、服务发布流程不够规范。过去的部署流程很简单，先是在本地测试，测试通过后，打包部署到线上，再观察服务的运行日志。但是随着团队人员和系统越来越多后，这种做法是不合适的。要想保证整个业务顺利上线，必须把服务发布流程规范化。从预发布测试到影响评估，到回滚步骤，再到灰度发布、线上验证，每一个环节都要标准化。预发布测试包含业务流程测试、新功能测试、SQL 验证、代码审查;影响评估包含对业务系统的影响和对交互系统的影响;回滚方案包含回滚步骤和回滚版本号，灰度发布则要按照按流量百分比、按设备类型和按 app 版本号等来操作;线上验证要做功能回归测试，以及观察异常日志、报警信息等。

　　10、研发规范不够标准。一个技术团队从10几个人发展到几百人甚至上千人的时候，规范很重要。为了提高效率，公司制定了各种标准的开发/操作规范，包括客户端开发规范、服务端开发规范、测试规范、运维规范、mysql、redis、kafka、mongoDB 等的使用规范。

　　未来对整个架构会有多个优化的目标，例如通过“微服务+容器化”实现服务实例的动态扩容与缩容、Service Mesh架构改造、业务级别的调用链跟踪功能等等。

　　最后，引用大家常说的一句话：好的系统不是设计出来的，而是演进出来的。未来，荔枝的系统架构会更加完善，在不断探索中更加精进。

（编辑：温州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!