荔枝架构实践与演进历程
参考原文地址：
2013年：单体架构
这个时候的架构是V1.0版,主要特点是APP 直连服务器，服务端是单体架构。也就是说，一个服务，一个存储解决所有问题。这种架构看上去简单、粗暴，好处是快速上线、快速响应市场需求;但劣势也非常明显，APP直连服务器模式在扩展的时候非常不灵活。项目上线后3个月，用户数突破 100万，访问量上涨，服务器压力增大。
2014年：垂直架构
到了2014年，荔枝APP的后台架构演进到V2.0版。这一版架构的特点是：支持水平扩展和功能拆分。首先，APP 与 app server 之间加入app代理层，用于分发请求给多台 app server，分摊压力。其次，对app server 按功能进行拆分，数据操作及业务逻辑部分由后端服务负责，并采用 netty(http) + json 方式进行交互。
2015年：分布式架构
V6.0版架构开启了分布式架构新征程，这时候的特点是app server、后端服务、代理层等，都实现了配置热更，能灵活水平扩展。到2015年9月，用户量曾突破 5千万。但是面临的问题依然很多。比如：mysql、redis 操作的重复代码太多;mysql、redis 慢操作不能及时报警;各个服务的数据源配置分散，难以管理等。另外，还涉及跨机房数据操作和数据同步问题。而分布式数据库中间件可以很好地解决这些问题。
2016年：分布式数据库中间件
从2016年开始，荔枝APP的后台架构走入V7.0版时代。这时，开发团队自研了分布式数据库中间件data store服务。data store的特点是：简单易用，可减少重复代码。只需要在类上加上注解，就可以实现与数据库的交互、数据转换等功能，大大减少了开发的工作量。另外，data store具有自动维护缓存和数据库表的对应关系、自动维护缓存与数据库数据的一致性的功能。最重要的是，屏蔽了服务对数据源的管理，便于数据库的迁移和扩容等操作。
2017-2018年：监控体系
进入2017年以后，整个架构已趋于完善，重点引入第三方产品，建立监控体系，完善对服务器资源、业务、跟踪链路等的监控，同时也扩展了分布式服务框架功能。也是从这个时候开始，整个架构迎来了V8.0版。经过完善后，业务监控及基础监控功能已比较完整，分布式服务框架扩展了接口缓存、熔断、降级、过载保护等功能。
主要问题及应对措施：
在高并发环境下，Mysql 查询性能成为瓶颈。当数据量呈现爆发式增长，Mysql 查询速度变慢。我们对分布式数据库中间件作了扩展，在操作mysql时，在数据库上层加入缓存memcached后，大大提高了查询性能,并且自动维护缓存和数据库数据的一致性。
随着业务的发展，系统的整体访问量越来越大，后端服务接口调用耗时越来越长，导致经常超时。经过分析和统计发现，整个平台实际上以“读多写少”的场景居多。有没有一个兼顾全局的解决方案呢?在分布式服务框架中开发“缓存接口”功能，解决了这个问题。其实有很多场景，我们是不需要实时看到最新数据的，即使新数据晚了30秒或者1分钟用户才看到，也是可以接受的。
、随着服务的增多，每个服务都有很多实例，导致整个架构的调用链路不清晰，也不能预知整体架构存在的瓶颈。引入skywalking 实现调用链跟踪功能后，能快速定位到线上故障和整个架构的性能瓶颈。