《1号店交易系统架构如何向“高并发高可用”演进》阅读笔记

本文知识方向：技术

本文知识难度：

近期看了一篇关于1号店交易系统架构如何演进的文章，整理了一些自己的理解。

1、在一个企业运转的初期，其后台系统基本都采用最为传统的系统架构，即：前端＋应用逻辑＋数据库

2、随着企业的发展，上面的架构逐渐会遇到以下问题：

1）前端及应用逻辑逐渐复杂，代码逻辑、业务逻辑交叉逐渐严重，相互影响。数据库表结构复杂。

2）由于业务量变大，数据库访问量变大，形成热点，高并发下业务响应慢。

3）数据库存在健壮性问题。数据库健壮性问题不单单指：灾难情况下存在单点，更重要的是，由于是一个整库，当其中少量业务逻辑出现问题时，居然影响了全局的服务。

4）面临扩容问题，oracle数据库成本极高。

3、解决办法：

1）将“前端”、“应用逻辑”层解耦。“功能与功能”拆解为“服务与服务”。服务间采用互相调用的方式进行设计，避免“多个功能”集成在一个大程序中。“调用”可以采用“微服务”的方式，服务分别部署在不同的服务器上，采用RPC方式通讯。

2）将数据库做“分库”处理。按照业务逻辑、读写分离逻辑等，进行“逻辑分库”，降低库与库之间的关联影响。对于超大库，如“订单库”，进一步进行“水平分库”，按不同的分组逻辑将订单落在不同的订单库上。通过这样的处理，一是解耦；二是分担了数据库上的压力，提升了处理能力；三是当某一库出现问题时，不影响其他业务；四是降低了对数据库的要求，由昂贵的oracle调整为开源mysql。

4、界定服务的边界和粒度非常重要，既不能拆的太散，太散导致服务与服务间调用时间变长。也不能太聚合，否则没达到解耦效果。电商最重要的服务可分为产品、用户、支付、订单。此外，由于“订单”有查询、下单等不同等级的大量操作，因此，建议要做到读写分离，读：用户、商家查询，写：下单、支付、充值。

5、时效性与事物一致性程度，决定了如何“分库”。实效性高的与实效性低的服务分开，事物一致性要求高的与一致性要求低的服务分开，同时，对于实效性要求高的可以使用缓存等技术。比如前端“库存”数量，不能说库存还有但下不了单（当然这种情况大电商也经常存在，但要尽量缩短不一致的时间）。

6、除要做到应用逻辑的解耦以外，还需要一些通用技术的支撑，除上面所说的缓存技术以外，还有数据库中间件，用于让前端及服务层更方便的调用到后台数据库，中间件将把请求路由到相应的分库，几乎实现透明访问数据库。让服务层投入更多精力在业务逻辑，而不是寻找哪个分库。还有消息中间件，帮助准实时（异步）的完成诸如下单成功后的增加积分、短信通知等处理。

7、最后，面向服务最大的问题就是服务边界问题，个人感觉需要的不仅仅是对技术的理解，更需要对业务的理解。这也是为何很多大企业开始着手企业级业务架构转型工作，目的也就是提炼业务共性，抽象服务模块。

保护原创，未经许可禁止通过自媒体刊载，已委托“维权骑士”(http://rightknights.com)为文章进行维权行动~分享到您的朋友圈才是义举哦～