可能部分来宾已经在外面看到过我的一些文章，但是正式开始之前还是想做一个小小的调查，在座的各位有没有对网商银行有过初步了解的？今天我的分享主要从这样几个方面进行：网商银行的发展现状、服务架构分层和实践、全链路压测、跨地域多机房切换等等。

网商银行基于阿里巴巴蚂蚁金服的自营体系，但是在PaaS层面有些不一样的地方，已经完成整个产品化的过程。现在整个基于微服务的单一化架构，核心思想就是基于数据来把拆分思路提升到接入层，就是每一个数据中心都有很多业务单元，更多的是承载核心业务逻辑，每个单元都会处理部分用户数据。共享单元也有一个大的特点，客户的数据也会放在共享单元给业务单元反馈，全域单元就是产品应用，比如满足批量处理的用户数据。

我们可以分成技术层、渠道层、开放层和运营层，有些原则也是和大家差不多的，常规的应用类型分为存款、信贷和理财，我们会把底层核心的云客户、云产品服务进行分离，也会考虑是不是满足批量交易或者后台小号交易，按照领域类型来看我们会进行清算、核算和资产类型划分，也会关注关键应用是否成就，需要满足单一化架构的约束，进行服务更加细致的划分。

全链路压测也是非常重要的条块，怎样探测我们的生产环境真实情况，挑战也是比较大的，早期就是所有核心业务都要满足全链路压测的要求，每个服务都会要求同时进到生产表和压测表，流量方面通过我们自己的压测平台进行数据准备，比较依赖于单元进行流量识别，生产流量和压测流量不会被判定为非法的安全工具。

我们真正实践过程当中发生多次，这些遗漏怎样进行兜底，我们很依赖于中心对流量的判断。微服务架构也有很多异构化的过程，进行压测的时候需要考虑过程当中会不会发生丢失，就是整个系统设计当中需要重点考虑。除了流量评估之外，我们每年的重大活动都是通过压测，早期的双核到多核，包括一些云产品的切换，整个过程都是依赖于怎样保证业务的稳定性，也是进行系统的预热，每个月都会有固定的窗口，可以看到我们业务的成功率是怎样的，通过自己的共享平台注入到只会影响到压测当中。

右上角这张图当中可以看到一个比较陡的曲线，比如100个分库，服务器扩容的时候会有一个更大的效应，就是导致整个数据库的后端崩溃，所以从这个角度来说，扩容其实是有一个比较明显的瓶颈。因为微服务架构提升是没有一个有序的管控，其实数据层面也会出现这种交叉的情况，由于控制线的问题就会导致所有的服务器崩溃，平时如果不进行流量日常化的运转，看起来资源利用率是非常低的。

我们可以看到某个具体数据单元进行二次逻辑划分，有的单元承载30%的流量，根据机房自身的服务器规模以及基础设施情况决定流量的配置，跨地域的部署就是解决机房的路由实验，内部也是用了一些改造，可能用户数据已经不在机房里面，所以需要进行二次转化，就是转化到正确的机房，需要判断这个数据是不是属于本单元，那么还会进行一次转化，核心就是用户定位和整个单元面对的关系，数据聚焦到单元也是依赖于这种协同服务。

我们在这个过程当中做的事情还是很多，大的挑战在于怎样把所有的机房做成一个整体，就是针对allocation进行跟进，然后归到请求的链路就可以完成整个过程，但是基础设施的配套过程还是比较漫长，花了一年多的时间，也有提升我们产品化的能力。

这是我们建设链路获得的很明显的红利，就是日常会有很多收益，也是基于整个一键切换的平台，就是需要把这个单元调成0%就可以，在这种情况下整个业务就会得到恢复，实践过程当中我们并不需要去找，只是集中在某个固定单元切换就可以了。整个机房所有单元都出现故障的话，我们只需要调到另外一个对应的单元，然后再把路由进行调整，就是要把所有UI切换过来，不仅是数据层面的，也包括上层应用的，都是流量控制中心当中进行调度。

每次重大架构升级做起来都会比较漫长，因为每个应用都要进行改造和回归，每个团队的资源情况也不一致，所以推动架构的过程非常漫长。未来我们希望把不是和业务强相关的逻辑下沉，这个过程当中只是把我们的安全架构和管控往下流转，整个APP规模也会明显下降，属于给我们未来体系打下基础。按照结构来看，我们的APP也是部署在一个Port上面，这种部署结构会带来比较好的特点，就是未来随着整个架构升级，不会有更多对业务的打扰，基础云和安全云都会得到发展，而且可以更好地控制自己版本发布，所以就会得到效益层面极大的提升。随着整个Service Mesh的落地，很多服务都可以提升出来。