|
物理部署架构 首先总括下我们的物理部署架构：请求通过前端域名进来，到达haproxy集群层，请求到达A B两个集群。然后到达我们的应用服务层，应用服务层通过调用各业务的SDK(SDK是组装了各rpc服务的一个逻辑整合层),两个红圈的地方这里做下说明，第一个红圈其实我们在实践操作中用网关层做了替代，接下来会说到网关。 微服务化 图1：微服务化原因 微服务化的一些原因，对应的其实也就是它的一些好处，这里不做特殊说明。 图2：微服务化的弊端 微服务化有这么多好处，但是同时也带来一些负产品，例如：系统微服务化后带来一个问题是系统变多了，相互之间的依赖变复杂了。一个业务的数据流有可能在几十个系统之间流转。这个时候系统监控和问题的排查难度加大了。另外之前一个系统有可能一个事务就能搞定的数据一致性，现在设计很多个系统如何做好分布式事务也是一个关键。 NOTE：微服务化虽好但要有度 网关 图3：网关架构图 网关在访问控制，统一安全控制，访问分析等方面起着重要作用，其实很多公司在架构层面并没有这一层，但是只是在功能上将此功能分散到了各个业务系统去了，比如安全防刷等； 网关的主要架构如上图，即，有一个专门的配置系统维护渠道，版本，功能三个维度的关系，例如android 的4.7.0版本首页功能模块指向哪个URL。数据先进入redis然后存储到数据库。如果真的线上要生效这个配置则要通过手动刷新zookeeper的节点，触发网关各应用服务器对此节点的监听，然后更新网关jvm内存。此时前端的访问过来的时候直接从各网关的服务器本地内存中就获取了相关配置。 NOTE：流量分发，安全管控，数据分析 LBS的缓存 图4：基于定位的缓存图 查询用户附近门店这是LBS服务中非常高频的一个功能，但是用户的地址经纬度变动非常灵敏，可能你从马路一边走到另外一边你的经纬度就变了，这时候根据用户的经纬度去你的门店的大的list中去遍历的时候你会发现速度非常慢，严重影响用户体验。这个地方我们引入了墨卡托投影，然后将地址划分成一个一个的格子，格子内的经纬度计算出来的值是一样的，这个时候我们根据经纬度为key，做缓存就成为了可能。 NOTE：响应时间从500ms降低到10ms 订单主架构 图5：订单主架构图 订单的详细流程不在这里赘述，这里主要说下需要注意的地方，toc下单和tob生产分离做到互不影响，另外toc订单管道对下游订单生产系统起保护作用，对什么时候多少流量起控制作用，削峰填谷。订单流程如此复杂，涉及了服务的依赖治理，数据一致性幂等性等题。接下来我们逐一分析： 图6：常见问题图 幂等性：为了防止业务上的重复操作，我们对库存，促销等资源消费的环节进行了幂等性操作。另外为了防止并发扣减等使用了redis分布式锁，incr，setnx等方式进行实现； 异步化&缓存化：其实所谓的及时响应，能够扛得住大并发。主要就是两个思路，异步化和缓存化。不影响主流程的能异步就异步，异步化我们常用的的是通过异步线程或者是MQ或者其他队列方式。缓存化我们常用的就是本地缓存，远程缓存，当然要注意这几种缓存的使用场景，才能发挥其最好的作用。 数据一致性问题：本系统内部的缓存，数据库，es等的数据一致，以及同外部系统的数据一致。这都是我们实践中常出现的问题，一个订单一侧是配送中了，为什么在另外一个系统还是待抢单。等等类似的问题。根据数据的一致性的强弱处理方式也不同，常见的就是用数据库的事务，worker队列，mq异步补偿，或者一些rpc框架自带的重试机制降低数据不一致性的概率。 过度设计：像一开始我们物理部署架构中第二个红框里面标出来的，这一层因为我们各个渠道的业务形态差别不是特别大，没必要单独的抽出SDK层，直接在web层就将所有的逻辑操作了。减少了维护和开发成本； 图7：存储组合示例图 我们日常常用到的这些存储方式，database,jvm,redis,zk,elasticsearch等。每种业务场景可能涉及到其中几种的使用组合，每种使用组合之间中间件的先后顺序又形成另外一种组合，例如先入库后入redis和先入redis后入库都是面对不同的业务场景。由于组合场景特别多，以后会作为单独的一个专题来说。这里想表达的是我们要根据实际的业务场景不断的经验化标准化我们的处理方案，为其他团队提供更高效低犯错率的解决方案。 NOTE：总结业务场景找到最优的组合方式是关键 高可用
图8：监控示例图 相信各个公司都有自己的监控，这里想说的是监控要做到全面化和可视化。经常发现有的系统监控很多，但是可视化程度不高。大家真正实践过程中会发现并不好用，甚至只有报警的时候才会去关注。 NOTE：全面化是基础，可视化是体验和可用易用的保障
图9：其他高可用图 灰度：在改动量特别大或者非常重要的功能不但业务上要进行ABtest，程序层面也要进行灰度。但是灰度的策略和实施是比较考验技术经验的。根据什么关键参数去灰度，既能让这个灰度场景体现出所有的场景又能尽可能少的影响生产，另外灰度的维度还对是否会产生脏数据，灰度失败进行回置的时候是否会产生恶性的连锁反应定都有关键的影响；此外在一些比较复杂的系统中在灰度的实施过程中经常会出现一些分支逻辑考虑不全导致事故的情况； 限流&降级：降级不是什么新鲜的事情了，这里我要说的是在做降级的时候要充分考虑对业务层面的影响。举例：运费在做降级的时候是不是调用失败是不是能统一降级为N元。这个要根据业务场景，有的鲜花蛋糕订单配送费非常高肯能降级成N元就不合适，而对普通商超订单可能就能接受。另外降级后对下游系统，商家生产，计费结算是不是有一些异常的影响。这些都要考虑，而不是简单的考虑自己的系统，降级了事。 限流是系统遇到瞬时洪峰或者系统负载异常时候，系统自我保护的最后一道防线，没有限流的系统不是一个健全的系统。限流有基于令牌桶算法的，漏桶算法的等，本机的还是集群的，web服务器层还是应用服务器层等。 压力测试：一般有极限压测和日常流程压测。极限压测为了验证系统的并发边界，日常流量压测可能更多的是验证系统的并发场景的逻辑健壮性。最重要的一点就是仿真，有的压测流量到了，但是数据太假。有的数据仿真了，但是模拟的流量和实际压测要求不匹配。 号外：达达-京东到家北京、上海、成都的研发中心正在大力招聘优秀工程师，欢迎入伙。北京、成都投简历至cvbj@imdada.cn ，上海投简历至cv@imdada.cn。 |
|
|
