正文
第四步是需要将业务逻辑下沉到服务，Web层专注于展示逻辑和编排，不要涉及过多业务的事情。然后用SOA中间件建设服务化系统。最后会做一些服务的治理。
来看一个API服务化的例子，在做服务化之前和做服务化之后，交易创建下单业务有什么不一样。服务化之前我们面临的问题有：入口分散，如果要在底层做任何一个微小的改动，十几个入口需要几十个人配合修改，这是非常不合理的一种方式；多端维护多套接口，成本非常高；还有稳定性的问题，依赖非常复杂，维护很难。
我刚到蘑菇街的时候，一次大促活动就导致数据库崩溃，暴露了系统架构很大的问题和总量上的瓶颈。按照上面提到几条思路去做服务化，看看有了哪些改善？首先是API统一，多个端、多个业务都用统一的API提供；其次是依赖有效管理起来，大事务拆分成多个本地小事务；最后降低了链路风险，逻辑更加清晰，稳定性更好。
![]()
2015年3月我来到蘑菇街之后，先制订了服务化的规范，探讨了到底什么是标准的服务化。在做服务化的过程中，发现大家代码风格完全不一样，所以制定编码规范非常重要。
2015年8月，我们完成了各个模块的改造，包括用户、商品、交易、订单、促销、退款等，然后有了服务化架构1.0的体系。在此基础之上，我们进一步做了提升流量和稳定性等更深度的建设。2015年9月，我们实施了分库分表和链路性能提升优化，2015年10月做了服务治理和服务保障。
![]()
接下来，
以服务架构和服务体系建设为主线，讲一下去年整个网站架构升级的过程。
![]()
在服务化1.0体系完成之后，我们得到了一个简单的体系，包含下单服务、营销服务、店铺服务、商品服务和用户服务，还有简单的RPC框架Tesla。当时，我们并没有做很多性能优化的事情，但是通过业务流程化简和逻辑优化，每秒最大订单数从400提升到1K，基础服务也都搭建了起来。
![]()
有了1.0初步的服务化体系之后，更进一步，我们一是要继续深入网站如资金等的服务化，二是要做服务内部的建设，比如容量、性能，这也是接下来要讲的内容。
购买链路的性能提升
![]()
这个链路（见图）是比较典型的电商链路，有商品页、下单、支付、营销和库存等内容。一开始每个点都有瓶颈，每个瓶颈都是一个篱笆，我们要正视它，然后翻越它。
![]()
我们先来看第一个篱笆墙：下单的瓶颈。
2015年“3.21”大促的时候，DB崩溃了，这个瓶颈很难突破。下一个订单要插入很多条数据记录到单DB的DB表。我们已经用了最好的硬件，但是瓶颈依然存在，最主要的问题就是DB单点，需要去掉单点，做成可水平扩展的。
流量上来了，到DB的行写入数是2万/秒，对DB的压力很大。写应该控制在一个合理的量，DB负载维持在较低水平，主从延时也才会在可控范围内。所以DB单点的问题非常凸显，这座大山必须迈过去，我们做了一个分库分表组件TSharding来实施分库分表。
![]()
将我们写的分库分表工具与业界方案对比，业界有淘宝TDDL Smart Client的方式，还有Google的Vitess等的Proxy方式，这两种成熟方案研发和运维的成本都太高，短期内我们接受不了，所以借鉴了Mybatis Plugin的方式，但Mybatis Plugin不支持数据源管理，也不支持事务。
我大概花了一周时间写了一个组件——自研分库分表组件TSharding（
https://github.com/baihui212/tsharding
），然后快速做出方案，把这个组件应用到交易的数据库，在服务层和DAO层，订单容量扩展到千亿量级，并且可以继续水平扩展。TSharding上线一年之后，我们将其开放出来。
![]()
第二个篱笆墙就是营销服务RT的问题。
促销方式非常多，包括各种红包、满减、打折、优惠券等。实际上促销的接口逻辑非常复杂，在“双11”备战的时候，面对这个复杂的接口，每轮链路压测促销服务都会发现问题，之后优化再压测，又发现新的问题。
我们来一起看看遇到的各种问题以及是如何解决的。首先是压测出现接口严重不可用，这里可以看到DB查询频次高，响应很慢，流量一上来，这个接口就崩溃了。那怎么去排查原因和解决呢？
首先是SQL优化，用工具识别慢SQL，即全链路跟踪系统Lurker。
