关于架构，我认为：架构没有好坏之分，只有得当的才是好的。架构不是设计出来的，而是摔打出来的。“物有本末，事有终始，知所先后，则近道矣”，这里跟大家谈谈土巴兔网站架构之道。
本日跟大家互换的架构之道，这个“道”实在包含两个含义：一是土巴兔网站架构的衍变进程；二是在这个进程中我们悟出的一些思想。
我把土巴兔网站架构演化分成三个阶段：
第一阶段
2008 年 ~ 2014 年，关键词：LAMP、裸奔
土巴兔 2008 年景立，刚开始的时候是一个非常大略的基于 LAMP 网站 (Linux + Apache + MySQL + PHP）。 LAMP 是开源的技能，建站速率快，开拓本钱低。土巴兔做的是装修 O2O，业务特点是线下业务繁芜、流程长、变革快，业务和产品都须要不断试错，技能要快速支撑。
到 2014 年，网站也逐渐变成了下图的架构：
大略去看，架构紧张分成三层：代理层、 Web 层和数据层。代理层紧张做的是负载均衡， Web 层卖力对要求进行处理交给 PHP 进行页面渲染， PHP 做了数据访问、业务逻辑和页面展现三件事。数据层我们也做了一些数据库高可用。比如 MySQL 的双 master 多 slave 的架构，运维本钱非常高。当时就一个运维，二十几个工程师。
随着业务的发展， C 轮融资，团队快速扩展，各种各样的业务代码（不管是网站还是 CRM）都往主站里塞，这样的架构存在非常明显的问题：
第一，性能问题。全体网站每个要求直接穿透到 DB，没有系统化的缓存体系。 比如当时 CRM 后台一个项目查询页面耗时一分多钟是很常见的事，严重影响事情效率。
第二，可用性问题。由于代码和数据的紧耦合，任何一个数据库慢查询，都会导致 PHP 进程堵塞， PHP 进程快速堆积，终极往上层蔓延导致全体网站打不开，造成雪崩。
第三，安全性问题。我们网站对付安全防御险些即是裸奔，事实也证明了问题的严重性，随着之后 2015 年土巴兔在行业内逐渐崭露锋芒，行业内竞争对手的恶意攻击 ( 例如 DDoS、 CC 攻击 )、乌云等第三方网站都暴露的安全漏洞尽出（例如 SQL 注入、 XSS 跨站脚本）。这些都对网站安全提出了极大的寻衅。
当时我们的机房在广州，时时时被攻击一下，导致网站打不开。IDC 机房的做事质量也比较差，更为严重的问题，不但是我们被攻击，同机房的其他网站被攻击我们也会受到牵连。俗话说，人怕出名猪怕壮，当时技能现状堪称是内忧外祸。
末了，可掩护性差，开拓低效。代码和数据的重度耦合，业务上但凡须要有一个流程或规则的变动，须要从头到尾全体链条式、大规模地改代码。掩护本钱随着业务数量的增长呈指数级增长。纵然到本日，全体 Web 层的代码依然耦合性非常高。
2014 年下半年，我刚加入土巴兔，面临这种粗放式的裸奔，我们意识到要有两手准备：首先是穿上内裤保护关键部位，其次是穿上外衣抵御寒冬。
第二阶段
2014 年 ~ 2016 年上半年，关键词：SOA、加固。
详细来说，我们紧张做了这几件事情：
首先是组建 Java 后台团队，搭建 SOA 架构体系，搭建新版 CRM 系统，把核心数据保护起来。
CRM 是土巴兔背后的生产系统，其主要性就好比客服、订单系统对付京东的主要性一样，它直接影响着业务链的生产效率。刚开始 SOA 接管的便是 CRM 最核心业务，把 CRM 数据查询性能进行全面优化。
首先要把 DB 开释出来，我们引入了搜索引擎 Elasticsearch，把繁芜的联表查询全部转移到业务逻辑层和 Elasticsearch 上去做。这样的改造很根本也很主要，由于只有 DB 稳定了，上层的业务才不会挂。
经由 SOA 化之后，无论多繁芜的查询，新版 CRM 页面的相应韶光都掌握在 200 毫秒之内。事情并不像大家想象地那么大略，如果从零开始架构一个别系，我相信并不会很困难，但是如果去升级一个已经在运行了好几年的业务系统，事情就不大略了。
当时组建的 Java 团队花了将近 2 个月才真正对业务逻辑、表构造梳理清楚（当时数据库 database 便是一个，而且有 1000 多张表，核心业务表的字段都是上百个）。只管表构造浩瀚不合理，也不敢冒然激进地对数据库构造进行大规模改造，只是在做事层做了封装，底层数据库基本没变，数据库根本不敢动，你不知道动的一个字段会对哪个 PHP 代码造成影响。遗憾的是，至今还没有机会和精力去对底层的数据进行分离和重构，很多业务还是 PHP 直接访问数据库。
其次，对网站高可用进行加固，代码支配分离，接入公有云防护和云缓存，建立多级缓存体系。
经历了 CRM 改版之后，我们深刻地相信，重构一个业务快速发展的网站后台难度是巨大的，尤其是当你每天还承载着 400 万 UV 以及你带的队友大多是一群刚毕业没多久的生瓜蛋的时候。因此，对网站的加固，紧张还是从运维的角度出发去做。大家写过 PHP 的该当都知道， PHP 处理一个 Web 要求是同步调用的，处理完就开释统统资源（例如 DB 连接、缓存连接等）。同步的办法编码很快，但是问题也很明显，但凡后台一个做事壅塞，那么这个要求也就壅塞直到超时。
在这种情形下，一种方法是把业务处理异步化，减少系统之间的依赖壅塞。但是异步化对技能的变革太大，我们只对部分关键业务做了异步化。
我们选择了其余一个种方法，那便是进行分离。分离有几个维度：读写分离、动静分离、业务分离。网站的代码和 CRM 代码分开支配。网站浏览类页面和用户发招标域名分。隔离的好处很明显，一个业务挂了不影响全局。网站大多数是读要求，只有很少部分用户会注册登录和进行操作。
基于读写分离和动静分离，我们利用了第三方云防护，结合自身的缓存体系，建立了一套从云缓存、 CDN，到代理层缓存，再到 PHP 静态化缓存，再到做事层的 Redis, es 的多级缓存体系。大略地说，从用户出发，对流量进行层层过滤，终极到达数据库的只是非常小的一部分（不到 1k 次要求/分钟）。同时，云端页面缓存是分布在全国很多节点上的，可以有效地抵抗 DDoS 类攻击。经由了这一轮的加固，纵然网站内部全部挂了，网站常常被访问的热点页面还是能打开，并且用户还是可以在土巴兔登记手机号码。利用云缓存还有一个好处便是，网站的首屏韶光已经降到 100 毫秒一下，跟淘宝和京东达到了同一水平。
除此之外，建立了一套线上全网层次化的监控体系，从前真个页面的性能、可达性监控、到后端做事层的波测监控，合营脚本自动故障转移，自动化告警（短信、微信、语音呼叫）。同时，针对乌云等网站暴露的漏洞，我们自研和运营了一套运用防火墙 (WAF) 系统、代码检测系统。 WAF 是通过支配在代理层 Nginx 做事器上的 Lua 脚本实现，每天防御恶意攻击数据： 20 万次旁边，并且防御规则持续运营。对付机房培植，我们也进行了大规模的升级，核心机房从广州迁移到北京，南方机房作为备份机房。
因此，第二阶段的网站架构如下图：
从这个图大家也可以看到，最上面第一层是公有云层，包括网宿 WSA 页面缓存、腾讯云页面缓存和 CDN。第一层基本上挡掉了大多数的流量。再往下，当页面缓存失落效时，云端会往下回源到代理层。代理层支配了 WAF 和页面缓存。代理层的页面缓存也会多虑掉一部分流量。再往下便是 Web 层，再往下是 SOA 做事层。当然目前 SOA 做得还不是很完善。从这个图中大家也可以看到有块空缺地方， PHP 穿透做事层直达数据库，这是架构设计不许可的。同时做事层也非常乱，做事管理做得还不足，这也是后面要努力去优化的方面。
这里提一下负载均衡，为什么用 7 层负载均衡，代替了原来了 4 层 LVS，实在也很随意马虎理解。 7 层 lb 是属于运用层的掌握，我们要实现 WAF，必须在运用层做，网络层只能实现很大略的防护。
其余，之以是没有先从内部一层一层去优化升级我们的网站性能，而直接用第三方的云端页面缓存这种大略却非常有效的手段，是由于内部优化须要经历的韶光会良久，耗费人力本钱很高，不可能一撮而就。作甚重作甚轻，这是主要的技能之道。因此，我们许可短韶光的做事化不彻底，由于网站高可用了，我们有足够的韶光去优化内部系统。
事实上，业务的高速发展，也不许可在网站高可用还没做好的情形下去全面升级 SOA。
经由了第二阶段的不断摔打和加固，网站的可用性和安全性基本达到哀求：现在土巴兔纵然核心机房的做事都挂了，网站还能打开，而且首屏韶光不差于淘宝京东。用户还能在我们的网站登记手机号码。但是，架构进化之路还很长，接下来我们要办理这些问题：
首先，职员新手多，开拓效率低，技能框架如何应对人才压力？随着业务的扩展，团队快速扩展和壮大的需求跟精良工程师比较难招的抵牾日益凸显。尤其是，我们总部落在腾讯大厦阁下，招人更加难上加难。作为一个创业团队来讲，我们做不到像 BAT 和 Google 一样，一届一届 985、 211 的精良毕业生进来，我们必须走出一条自己的路。也便是说：我们团队要做出还不错的东西，但是我们又不能过于依赖人的精良，我们只能依赖傻瓜化的框架。
其次，代码交付频繁、交付质量差。业务的变更频繁，根据统计，我们常常一周发生 200 多次线上变更。当时我们运维团队就 3 个人。在 2015 年的时候我们的压力是非常大的。交付多了也直接导致质量就变差。我们的程序员在写一个 PHP 页面的时候，常常一个非常没有处理，页面就打不开了，导致缓存回源失落败。
其余，SOA 并没有彻底，做事也会越来越多，如何管理？虽然在第二阶段通过一些云缓存从外部做了保护，但是我们网站内部的构造还是比较薄弱。如何由内而外地对我们后端系统进行管理和加固，是下一阶段的重点。
第三阶段
2016 年下半年往后，我们关于架构的关键词是：傻瓜化、全面做事化、流程化、标准化。
其实在去年年底我们就已经开始思考，傻瓜化框架该当是怎么样的？土巴兔的技能 3.0 该怎么去做？
我们认为，傻瓜化的框架便是让新挂蛋能很快上手做业务开拓，不用学习太多，就像我们利用 iPhone 拍照，就算不是专业的拍照师，也能拍出比较好的照片。
傻瓜化的框架也能担保 PHP 在渲染了一个非常页面的时候，不让这个页面吐出去给用户访问到，而是自动地吐出一个哪怕历史的正常页面。
傻瓜化的框架可以让开发不须要关注数据存在哪里，数据是否要从数据库到搜索引擎进行同步，如何同步，如何缓存等问题，只要根据 SDK 调用就行。
心腹知彼，方能百战不怡，我们的团队跟 BAT 的团队比，不敷在于：我们的开拓职员能力没那么强，团队也没那么多人；但这也正好也是我们上风：小的团队，可以动物脱兔，随意马虎统一标准，统一框架。因此我们把一组能力最强的人抽出来专门开拓工具和框架。用工具去武装我们的新兵。
企业经由了粗放式地奔跑，到了一定的阶段，就必须停下来修炼内功欢迎下一阶段的寻衅，就必须要去培植标准化平台。高效管理做事也是一个比较大的话题，本日的分享我并不想说太多。我只说说关于技能 3.0 之路，我们做的一些考试测验和方案。
首先是 SOA，我们方案的 SOA 是层次化的，如下图：
纵向来看，我们将 SOA 架构划分成 5 个层次：展示层、流程做事层、运用做事层、数据做事层、根本做事层。横向来看，各个业务对应的做事相互独立（根本做事除外）。一样平常来说，每个做事都属于某个业务，一个业务定义了一组干系的流程、做事及数据。业务内部的干系流程做事具有相对的紧耦合特性，跨业务之间的做事和流程相对独立。
展示层：展示层紧张是 Web 层，紧张是 PHP 这一层。
流程做事层：流程做事层包含了跟业务流程干系的做事。
运用做事层：定义了相对独立的业务逻辑，供 PHP、其他运用做事、或者流程节点做事调用。运用做事可以调用属于自己（逐一对应）的数据做事，以及其他运用做事。运用做事供应对业务数据对外暴露的接口，对业务数据进行有效保护。换句话说，如果某个运用要访问某个业务的某个数据，必须通过这个数据对应的运用做事接口来实现，不能直接调用这个数据做事。运用做事是对我们底层数据的有效隔离和保护。
数据做事层：数据做事是最底层的做事，它封装了跟数据交互的基本 CRUD 接口，对付上层的运用做事来说数据做事屏蔽了访问存储举动步伐的细节，只供应抽象的访问接口。数据做事内部定义看了业务领域的数据工具，这些工具是通过业务编号 + 做事编号 + 工具名来全局唯一标识。一个数据做事只许可对应一个运用做事来访问，对数据进行了有效掌握和隔离。我们可以大略地理解成数据做事层便是办理数据访问的问题，但是又是傻瓜式地访问。
根本做事层：根本做事不属于任何业务，包含了一些公共的做事组件，例如日志做事、做事等。运用做事之间可以相互调用，为了简洁，图上没画箭头。
大家理解一下，对付 O2O 公司来讲，每天变革的实在便是业务，业务的什么东西在变？实在便是流程和规则的变来变去。我们希望下面运用做事层和数据层变得没有那么多，相对固定，而流程是可以常常变的，这便是要分层管理的缘故原由。我们也引入了一些流程引擎、规则引擎，以技能之不变应业务之万变。在这种分层管理的架构之下，业务须要开拓新的流程，只须要支配一套新的流程图，同时合营流程节点的对应的业务做事插拔到这个流程中去，流程做事聚合运用做事来快速实现我们的业务，这是我们未来希望达到的目标。
SOA 是个很大的范畴，我重点讲讲我们如何做傻瓜化的数据做事：
基于之前利用 Elasticsearch 来做繁芜数据查询的履历，后来很多业务系统凡是有一些繁芜的联表查询都开始利用 MySQL + es 的存储模式， MySQL 存原始数据，做一些大略的 KV 查询， es 做繁芜的联表查询和数据聚合统计。后来业务开拓的同学都要去学习 MySQL 和 es，并且还要学习如何从 DB 同步数据到 es 等重复性的事情。因此我们希望把这些建表、查询、数据同步等繁芜的事情抽象出来，让框架去做，开拓只管卖力描述业务逻辑的数据 schema：数据构造和关系。这便是为什么我们提出傻瓜化的数据做事的思想，如下图：
与其说这是一个做事，不如说这是一个数据开拓平台，通过这个平台，开拓只须要定义数据 schema，我们用 JSON 去描述这种数据的 schema，这种 schema 跟 SQL 的建表语句类似，但是表达能力更强。这种数据描述是一种中间措辞，可以同时转化成 SQL 的建表语句和 Elasticsearch 的 mapping 定义。从上图可以看出，实在 schema 便是类似于 ER 图，描述了工具和工具之间的关系。我们的框架会根据 schema 定义自动天生数据访问 SDK，开拓只须要拿 SDK 来访问数据就行，利用例子见上图右上角代码段。实在 SDK 只是一个 HTTP 的客户端，对付数据的真正访问时在我们的数据做事中完成，所有关于数据的持久化、查询路由、缓存、权限掌握的逻辑都在数据做事层做，客户端是非常轻的。 DB 和缓存、 ES 之间的同步也由数据做事平台自动完成。
这里重点说一下，我们如何去办理联表查询的问题呢？我们在定义 schema 的时候，会把须要联表查询的多元关系描述成一个冗余工具，例如我们有一个 Book(ID,name) 工具和一个 Author(ID,name) 工具。同时我们有一个关系表来描述两者的关系，因此我们在 schema 里定义了一个 AuthorBook 工具，里面包含 author_id 和 book_id 两个原始字段。我们的业务可能须要根据 author 的名字查找 Book。这时，我们的做法便是在 DB 的 AuthorBook 表里只存储 author_id 和 book_id 这两个 ID 字段，而在 es 的 AuthorBook 这个关系表里除了存储两个 ID 之外，还有两个冗余字段： author_name 和 book_name，同时平台担保了这两个字段跟 DB 里面 Author 表和 Book 表里面的 name 保持实时同步。为了做到这样的效果，我们在 schema 中这样描述 AuthorBook 工具：
我们对字段的同步关系进行了描述，就像 DB 的外键一样，描述了 author_name 同步自 Author 表的 name 字段，利用 author_id 作为外键跟 Author 表的 ID 关联。通过这种办法，理论上能办理联表查询的繁芜度，统统都变成 ES 的单表查询。
当然，这个数据做事平台的推广还没有大面积展开，目前还在单个业务的试用跟测试阶段，而且一个比较大的寻衅便是数据同步，我们还没有做得非常强大，之后在推广过程中一定会碰着很多问题须要完善，敬请期待。当然，我们也希望等我们的平台完善之后争取能开源出来，帮助更多企业提高效率。相信利用我们的数据做事之后，后台做事的开拓将会变得非常随意马虎。
末了再说说网页容错问题，后台数据库挂掉或者后台做事非常都会导致页面展现非常，乃至全体页面就挂了。针对这种问题我们也作了总结反思，我们有必要搭建一个能监测缺点的舞台。如果说我们的网站是一个舞台，那么页面上展示的内容便是舞台上的演员和演出，我们要担保这个舞台的演出不会出错，因此我们建立了一种非常页面的检测机制。如果说这个内容不太正常，那这个舞台是不许可你上台的。当我们上线一个新的页面的时候，根据历史的页面我们做一些相似度的检测，如果创造这个相似度差异非常大，就要告警，框架就不给你上，换而去找出最近的一个正常的历史页面吐出来。我们做任何技能框架都坚持一个假设：开拓会犯错，而且会持续犯错。
在土巴兔，关于技能架构方面的事情可以谈很多，由于篇幅关系今天主要跟大家先容上面这三个阶段的重点，欢迎大家留言中批评示正。
末了我轻微总结一下，个人对技能或架构的一些感悟：
Q&A
提问：想理解下这种按业务划分各系统，系统间交互怎么定义？比如我们目前的问题是各业务系统协作效率不高，环境老出问题，不是版本不对便是依赖的系统不支持。
张华杰：关于系统之间的交互，我们定义了一套标准的协议，系统之间都是通过总线进行调用，有了标准协议，只须要各团队卖力掩护自己做事的稳定就行了。关于版本升级，系统之间通过 RPC 调用，系统之间的兼容性问题更多的是做事 api 接口的升级，我们通过平台担保了升级的向下兼容性，其余，须要大家统一一套缺点码规范。关于系统之间接口的参数合法性验证也是很主要的事情，我们利用开源自己定义了一套参数自动考验规范。
监控告警也是主要的一环，新系统上线必须有压测和自动拨测，以及标准的监控数据上报，否则运维是不给上线的。
提问：土巴兔目测有 20+ 多个城市的站点，400W UV 是打到一个机房还是每个城市均衡? 方便透露一二线城市跟三四线城市的流量占比是若何的吗?
张华杰：我们的流量紧张是分布到网宿全国 60 - 70 多个缓存节点上的，对用户都是就近访问。当然，当缓存失落效的时候须要回源，回源的流量紧张回到我们北京核心机房，我看了一下，峰值每秒一千多要求量。流量的话一线城市霸占了 50% 以上，剩余的城市占了一半。多亏网宿和腾讯云才担保了我们核心机房的无压力。实在，对付我们这样重度依赖线下的家装 O2O 公司来说，内部 CRM 系统的流量跟 C 端用户的回源流量是相称的，由于我们每天有上千人同时在全国各地访问我们内部的 CRM 系统，往后会更多，而且会接入各种移动终端，这对付我们内部 IT 系统的优化和升级提出了更大的寻衅。以是，网站的流量反而不是我们当前最棘手的问题。
提问：如果现在回过分去看，并且你知道后续会是这个现状，会把当时的 LAMP 架构用怎么样的架构替代，来一定程度的担保后续的扩展更具灵巧性？
张华杰：如果从头来过，我们一定还是从 LAMP 开始建站。 这么做的缘故原由很大略，创业公司一定要快， LAMP 建站本钱非常低，招人门槛也低。其余，如果可以的话，建议创业公司只管即便把自己的做事支配到公有云。缘故原由很大略，也是快速有效。你不须要拥有一支很强的研发和运维班子就可以把事完成了。用别人的云平台可以大大降落试错的本钱。其余，如果有可能，我还是建议尽可能把数据层和逻辑层沉到 SOA 层去做。数据这一层的方案须要非常懂业务和懂技能的人去做，至少数据从一开始就要垂直化。数据对付技能架构是很主要的环节，如果事后再去优化架构，就会创造实在架构并不难设计，但是现有数据拆离和优化才是最难的。我们当前业务有 1000 多张表，全部塞在一个数据库里，纵然再牛逼得架构师，要去重构它们都是非常难的，由于我们要担保业务的持续稳定。这便是为什么我们要做傻瓜化数据做事，我们想去从数据层改造，但是将会非常困难。这便是历史的债。
提问：上文提到一种数据库 schema 描述的方法，这个目的是什么？
张华杰：我们做了全体 CRM 的改造升级，在改造升级的时候我们碰着了很多的问题，例如我们 CRM 很多后台的页面，有一些繁芜的联表查询很慢，把 DB 累得半去世。我们把这种繁芜查询都转到搜索引擎中去做，让 MySQL 只做一些大略的健值查询，由于 MySQL 并不善于做繁芜的打算。怎么把繁芜查询转到 Elasticsearch 中去呢？那就须要把很多表的信息冗余到 ES 的一张表中去。并且，我们通过这种数据的映射关系，掩护了 es 数据跟 MySQL 的实时同步。事实也证明了，用 ES 加数据冗余，确实可以提高实时查询的效率。这种方法逐渐被更多业务所采取，但是这样做会增加很多额外本钱，例如 ES 跟 MySQL 的数据同步就比较麻烦。因此我们把 MySQL 跟 ES 的数据映射关系进行抽象描述，用一种通用的数据定义措辞（ DDL）去描述，也便是我们所说的 schema。详细来讲， schema 描述了两个东西：一个便是工具（包括工具的属性），第二个便是工具之间的关系。一旦定义了 schema，它可以自动转换成 MySQL 和 ES 的建表语句。并且，数据同步做事可以识别个中的数据冗余关系进行自动同步，而不须要开拓自己写代码掩护数据同步。我们做这个事情的目的，便是希望业务开拓程序员不须要去关注数据存哪里、怎么访问、怎么建表、怎么索引等事情。他只须要把业务数据描述成 schema，我们的平台就能自动天生数据访问的 SDK。开拓只须要引入 SDK 直接调用就行了。 SDK 的实现是通过 RPC 调用数据做事，统统数据访问都被收拢和隔离到数据做事中去。这么做有很多好处：
首先，对数据的访问进行了统一的掌握和隔离。我们可以掌握谁能访问什么数据，谁不能访问。
其次，数据做事本身是对数据访问的一种代理，我们可以在存储层做各种性能和可用性优化。做事会去判断查询该当是走搜索引擎的还是 MySQL。我们不让开发直接写 SQL 访问数据库或者 ES，这样可以减少开拓犯错的机会，由于开拓常常不把稳写一些慢 SQL 把 DB 卡半去世。如果将来 MySQL 不再适宜我们的运用处景，我们也可以在数据做事层更换成其他的存储引擎而不须要改动上层代码。
末了，数据做事通过对数据访问的收敛和掌握，供应了对数据层的运营能力。例如，之前我们开拓对数据库表加了一些字段，很多年之后可能这些字段都弃用了，但是 DBA 也不知道，数据库始终保留着这些垃圾字段和数据。我们希望数据平台统计出这些信息，帮助 DBA 创造这些垃圾字段，并提示 DBA 去清理。
提问：这个平台现在已经在用了吗？
张华杰：实在我们已经内测了，接下来会把我们核心业务的核心数据进行升级到这种数据做事上去。但是目前数据同步模块还存在一些问题，由于数据同步做事须要根据 schema 定义的数据依赖关系来进行 DB 到 ES 的数据实时同步和冗余。这个模块比较繁芜，还在改进阶段。而且，根据我们目前数据库的繁芜程度，我相信数据平台的真正全面推广，并担保现有业务的平顺迁移，可能须要花半年以上的韶光。
提问：我还是不太确定可不可以达到你的期望？理论上是把这个数据搬过去，自动帮你建立索引，他什么都不用做，关键是这一点我不太确定。
张华杰：确实这个听上去非常空想。但是你真正去理解业务的过程中，你会创造实在大多数的情形，大多数的业务都是大略的查询，没有那么多繁芜的，当然繁芜的也可以做。我以为我们这个框架的目的是为理解决 80% 的问题。这个东西不是万能的，但是我们希望它能办理大多数的问题。这便是二八的原则。当然，要做建哪些索引，这些其实在 schema 里面已经描述清楚了，数据字段的类型，长度约束，来源等，乃至哪些数据只须要查 DB，不须要做 es 冗余都能在 schema 里描述，那么自动建索引理论上也是可以实现的。当然，数据同步是一个比较繁芜的问题，尤其是涉及到跨业务的数据同步，同步程序必须写得很健壮很通用，这里有难度，但是这种繁芜是值得的，由于开拓就大略了。
提问：繁芜查询也是供应给线上访问的吗？有一个很快的相应韶光？
张华杰：对。你可以想象我繁芜查询如果在 DB 里面可能要跑到秒级别，我把这些数据冗余到 ES 集群里，相应韶光基本能到百毫秒以内。实在也不是什么很博识的技能，便是用空间换来了韶光。
提问：你做索引的数据膨胀有多大？举个例子，原来一台 MySQL 或者是两台 MySQL，你把它搬到 ES 里面，你是用两台还是多少台可以盛得下？有没有放大？
张华杰：一定会放大，如果冗余得多，数据的大小可能翻好几倍，例如我们的一个核心业务数据，有大概 10 张表组成，在 es 里面除了这 10 张表自身的数据之外，还有一张集成的大表，把 10 张表的数据冗余在一起。对付我们而言，数据量并没有达到海量，历史项目加起来便是几千万级别的。我们的做事是各业务垂直拆分相互隔离的，各个数据可以平行扩展。你可以理解成，每个业务放在自己的独立的桶里，每个桶分担的量并没有那么大。之前我们访问压力大的缘故原由是所有数据都在一个桶里。拆分之后就不会有这种问题。其余，Elasticsearch 天生便是分布式的，节点可以配置分片和复制，集群可以动态伸缩，对付数据规模的调度也是比较灵巧，它不像 MySQL 那样伸缩性比较差，这也是为什么我们选择 Elasticsearch 的缘故原由。
提问：你刚才说的要把它变成配置化，实在对付开拓职员来说是须要去理解这个配置的。以前我们做的这个事情，做实时指标的打算，实际上是把配置化变成 schema 化的。我们认为在数据统计里面是最好理解的一个措辞，以前的配置化在我们自己的系统内是自己定义的一套规则，让别人花更多本钱去理解这套规则，我不知道这方面的本钱你是怎么去权衡的？
张华杰：开拓会花一些额外的本钱去理解这种数据描述措辞，但是也不完备是这样，我们通过开拓一些 GUI 工具来帮助用户更快地建立 DDL，这须要一整套平台的支持 ，把规则和约束做到 Web 交互中去 ，目前这个平台已经做得七七八八了。 当你的企业利用的数据库种类很多的时候，统一的数据描述措辞是很有必要的，这更多是一种思想，你学会这种思想比你学会一种标准更主要。对付开拓来说，这种 schema 跟 SQL 建表语句类似，对懂 SQL 的人来说是比较随意马虎节制的。乃至，我们可以专门让领域专家集中去做数据的描述，这样开拓就更加解放了。
提问：我有一个问题。我现在是在一个创业公司，我们公司也碰着了被别人攻击的事情，我们公司的技能参差也是不齐，每个人都写一个后台代码，你前台的数据可能是不合法的，现在的创业公司很多都没有安全意识，你们是怎么办理这些问题的？
张华杰：我们用了一些共有云，比如说腾讯云、阿里云，他们都有安全方面的做事，你刚才说的是运用的防火墙 (WAF)，其余还有 DDoS 攻击，我以为一些互联网巨子已经做了，只须要拿来主义。其余，我们内部自己做了一个 WAF，如果当时我早知道腾讯有的话，我们可能会先拿过来用，自己一开始不会花那么大精力去做。我们自己还做了一些代码漏洞的检测小工具。我还是建议创业公司可以考虑一下公有云，直接用就行了，先顶住，再优化。
