工作不到一年，做出了100k系统，老板给我升职加薪

　　推荐阅读：基于SSMShiroLayuiEasyui权限管理系统超详细的MySQL工作原理体系结构OAuth2。0分布式系统环境搭建
　　看了下自己上一次发技术文还是在6月15日，算了算也是两个来月了。别怕，短暂的离开，是为了更好的相遇。
　　来到新公司以后啊，发现公司的搜索业务是真的太多了，大大小小有几百个搜索业务。来了之后得先梳理、熟悉业务，才能有所产出嘛。
　　但是，在工作了大概一个月的时候，优秀的龙叔发现，这组内的系统优化空间很大啊，简直可以说巨大啊。
　　所以说，即便是完善的大公司，机会也是有的，大家在自己的工作岗位上也要好好把握机会。在公司想要得到好的提升，主要有三方面可以发力：第一、直接业务价值显著，比如具体的PV、UV值提升了多少个点；第二、系统架构迭代升级或者重构，间接带来了用户体验、或者业务价值；第三、技术突破，在某个领域方向上做到技术突破或者创新；
　　小伙伴们，升职加薪指日可待啊。。。
　　这些系统都是历史包袱沉重啊，是不是感觉历史包袱这个词很熟悉，对于去搞一些历史包袱很沉重的工程，我们惯用的方法是是什么呢？当然是直接重构他
　　这对于工作不满一年的龙叔来说还是蛮有挑战的，但咱不怕，去做更具挑战性的事，才能更好的锻炼我们的能力，才会意义非凡。
　　反复思考，反复琢磨了几天后，向leader提出了系统重构的大致方案。一般在公司你想做什么都可以和leader提出来，互联网公司还是比较open的，但是leader会不会采纳你的方案就不一定了。
　　其实，龙叔对于自己已经画了很多方案图，调查很多业务场景、做了很多讨论之后做的方案还是蛮有信心的。
　　做就做好准备，不然就是浪费机会。
　　好了，接下来就不废话了，从几个方面说说这次系统设计：
　　背景介绍
　　大家都知道龙叔是做搜索的，所以这次的系统肯定是和搜索相关的，先和大家唠唠搜索整体链路，搜索链路主要分这几个部分，给大家画个图。
　　搜索引擎链路都包含这三部分，数据源、搜索引擎服务、搜索业务。是不是很简单，感觉搜索也没那么难。
　　搜索链路确实都包括这三部分，但没我说的那么简单，每两个部分之间链路很长，业务非常复杂。举例说下数据源到搜索引擎服务的链路。
　　首先数据源不是单一数据源、比如说个电商场景的数据源，主要有商家商品数据、用户数据、爬虫数据等多种数据源。
　　我这次要做的链路是从数据源到搜索引擎服务这一段，简单点就是数据源提供的数据，需要结构化之后入到搜索引擎，这样搜索引擎才能提供搜索服务。
　　可这数据源真的是五花八门，提供数据的方式也是五花八门的。设计步骤
　　背景基本就介绍到这里了，接下来就说说设计一个系统的步骤。说实话，毕竟是第一次做系统设计，当时真的是无从下手。不过帅气的龙su有法宝啊，多请教，多思考，多查资料。
　　在方案评审之前我已经做了很多方案设计图，这部分的努力主要是为了通过方案评审，这非常重要，通不过评审，老板不会让你做，就没有资源可以用，这项目就搁浅了。
　　这部分主要从以下几个步骤发力：
　　旧系统摸底。找出旧系统的所有不支持当前业务场景的点，有哪些是对当前业务影响较大的，哪些是对未来业务影响较大的，这些都要细细整理出来。不过这块我做起来还算轻松，旧系统在设计架构上就被我找到很多问题。
　　可能真的是由于历史原因吧，以前搜索是一个BU，现在只是大数据里的一个组了，这中间经历了多少改朝换代啊，历史包袱重的无法背负了，只能选择抛弃他了。
　　从上面的架构图可以很清晰的看出来这个系统有三个严重问题：
　　第一个、业务层数据到达队列完全依赖于业务方上报。这本来是件无可厚非的事，你要用搜索引擎，那就得上报数据来。就好比你用数据库，你总得把数据存进去吧。
　　但这事在公司行不通，历史包袱太沉重。业务方完全不想上报数据，虽然勉强上报，经常增量数据丢失。这一丢失数据导致搜索出不来。最终还是咱的锅，这。。。
　　总结下，就是业务方不想上报数据、上报数据总是丢失，锅还得搜索来背。
　　第二个、数据处理完成直接交付给数据应用，这个问题蛮严重的。数据处理其实意味着会消耗大量的计算资源和时间，而一旦数据应用层服务挂掉或者崩溃，将会导致服务短时间无法恢复。
　　比如1000w的数据处理需要一个24core机器处理12小时，一旦下游的solr或者RS集群崩溃，把一份全量数据恢复回来，需要数据处理系统重新计算12小时，这恢复时间谁顶的住啊？
　　由于第一个问题存在，也就是数据上报容易丢失，所以必须依靠全量数据来恢复丢失的增量，我们的近200个业务基本每天都会做一次全量，这可是大把的计算资源浪费啊。
　　资源浪费一点倒也还好，但是这异常情况下的数据恢复时间确实是个大问题，用户可等不及这么长时间啊。
　　总结下，就是计算资源浪费，数据应用层服务无法做到无状态，恢复成本高昂。
　　第三个、数据处理系统耦合度太高，系统太复杂，维护困难。数据处理一般包括数据清洗和业务组装，数据清洗可以算作是业务变化较少的，但是业务组装规则是灵活多变的，这部分经常会由于业务方的变动而产生开发的需求。
　　业务变动频繁、业务繁多导致系统变得复杂，系统复杂耦合度还很高，导致这个系统维护和开发成本很大，日常需求开发已经成为难题了。
　　业务场景调查。搜索有很多场景，比如电商场景，内容场景，直播场景。场景很多，公司业务形态上也是都有这些，但不是所有的场景都使用了我们的搜索服务。
　　要去摸底一下那些没有使用的为啥没用，没用肯定是我们做的不好，摸底的主要目标的就是搞清楚到底哪点不好。深入到业务上去了解，才能更好的设计系统。
　　新系统设计。前两步骤已经找到了旧系统缺陷和业务问题，新的系统首先要解决之前的问题，其次就是做一些前瞻性的设计。
　　新系统设计这块包括以下几个步骤：
　　业务梳理这块其实在旧系统摸底和业务调查的时候已经做的差不多了，只需要在精细化的梳理下。
　　业务抽象业务抽象指的是一系列的业务问题，抽象为一种通用的解决方案。这块蛮复杂的，在这块需要花费大量时间。
　　技术调研每一种技术都有他的适用场景。举个例子，使用搜索引擎，到底是用solr还是用es、还是自研呢？这就需要你对技术方案有了解，知道这些技术方案的优缺点，最终才能找出适合业务发展的技术方案。
　　方案探讨好的设计不是一蹴而就的，也不是某个人的智慧象征。好的设计是一群人智慧的结晶，是一个不断迭代的产品，所以需要多讨论。
　　方案确定前面的问题解决了，基本方案差不多也该定下来了。为保证方案不会出现返工情况，你需要再拉上leader开个最终的项目方案评审会加上确定项目排期。架构图介绍
　　说了那么多好像还没说到我的设计到底在哪里，接下里就来说说我的设计。
　　在整个设计中我也做了好几版的设计图，草稿就不放出来了，直接放最终的一版设计方案来说，中间解释的时候会说那些演进的点。
　　首先我设计这个系统目标有如下：零上报指的是数据不依赖业务方上报，有数据变更立刻感知到准实时数据变更之后实时进入引擎，提供搜索服务高吞吐高容错低耦合易维护
　　这几个目标已经完全解决了之前系统存在的问题，比如上报数据问题，资源浪费问题，紧急恢复时间长的问题。
　　整体上我采用了分层设计方案结合微服务的思想，把复杂的问题分层抽象，各层次之间功能单一且分明，耦合度低，维护方便。
　　当然这样的设计会导致数据链路变得略长，会有多余的网络传输延时。现在的网卡已经够大了，网络传输在这个项目中不是不足为虑。
　　自上而下，沿着数据流动的方向，逐层解释下为何这么设计：
　　第一层，业务数据层，这是不变的，一致存在的。目前我们共有快200个业务场景，每个业务方的数据源是不同的，同时也有交叉的，比如商品数据在类目搜索、内容搜索、订单搜索、商品推荐上都使用，他们确是不同的业务场景，数据有交叉也有不同。
　　但其实这里我们不必太关心业务方的数据来源，不管是何种来源最终都会有一个存储介质，只需要关心数据实际存储在哪里的。
　　把多种存储介质抽象出来，用一个服务去监听这些介质的数据变更行为，这就是接下来的数据监听层。
　　第二层，数据监听层。主要负责监听变更的业务数据，把变更的数据获取到，用规定的格式输出到下游队列即可。
　　第三层，数据缓冲层。数据缓冲一般用在系统与系统之间，通常情况下不要让系统与系统之间直接传递数据，这样的数据传递会有很高的风险，得依赖接收端系统的稳定性。
　　有了数据缓冲，系统之间就不直接交互数据了，系统之间没什么依赖关系，也不会互相影响。
　　第四层，数据处理层。这一层最终需要把零散的、不规则的数据处理为一个搜索可用的DOC数据。这块任务蛮艰巨的，当时在讨论这一层的时候，花费了很多时间。
　　数据处理包括两部分，一部分是一些通用型处理，比如去html标签、数据格式int转string等等处理逻辑；另一部分是一些变化较多的业务部分，比如一个doc有十五个字段，其中有三个来自A业务，三个来自B业务，而这些来自都是需要实时去业务方拿结果的。再比如对DOC中的字段会进行一些计算操作，具体计算规则根据业务而定的。
　　这些操作都很依赖于业务方，变化之多，很难把控。所以这块在设计上需要很灵活。
　　根据抽取出的这两部分特性，把不变的通用性较强的那部分定义为数据清理，用一个单独服务处理，这里采用sparkstream流去实时做数据清洗，处理完成之后输出到kafka队列。
　　灵活变化的部分用一个单独服务处理，业务变更采用脚本方式动态发布，修改灵活、即时生效。
　　第五层，数据存储层。故名思义就是做一个存储，前面已经计算好了一个完整的DOC数据。整个计算过程已经耗费了计算资源和时间，所以必须存储起来。一旦数据应用层服务数据异常，可以很及时用这里的数据做恢复。
　　不需要计算，直接拿过去用，恢复起来成本够低了吧。
　　有了存储层，既可以保证下游服务可以完全无状态，还可以保证快速恢复，同时还可以用作全量数据。龙su简直是个设计天才，前途无量啊。。。。
　　一边写到存储层，也会一边写到kafka队列，数据应用层需要获取kakka队列数据做增量索引。
　　整个分层的设计架构就是这样了，中间的业务细节就不一一讲解了。
　　懂搜索的朋友肯定会说了，这里的整个系统说的都是增量，那全量怎么更新。
　　这就到点上了，全量我采用了主动触发的方式，可以想一想那些场景需要做一次全量。
　　第一、业务发生了字段级别的变更，比如增加了一个字段，或者某个字段的全部值发生了变化。
　　第二、第一次接进来的业务，但已经有很大一部分原始数据。
　　第三、有大批增量丢失，导致无法通过容错机制恢复，而且不是很确定丢失那些增量。
　　第四、存储层有脏数据。
　　第五、数据应用层有脏数据或者异常了。
　　两种方式做全量，一种是需要计算的，通过增量链路计算做一份全量。另一种是直接通过hbase全量数据来做全量。
　　hbase有脏数据的情况下只能重新计算，或者清理脏数据。架构设计注意点
　　整体的系统架构主要由我完成，系统开发那可是集结了全组的功力。总共用时一个Q出了第一版，目前线上已经跑了好几个业务，最高qps能达到100k，截了一个线上运行的7天业务指标图。
　　说下一些注意点，希望对大家有用。
　　设计前对业务一定要非常熟悉，这样设计出的系统才能更好的服务业务多做技术方案调查，只有见的多了你才会思考的多了，思考的多了才会有所见解多沟通，很多问题自己一个人想着可能很完美，但很可能这时你钻到思维的牛角尖了，沟通能减少这样的错误
　　设计中多画架构图，画出来便于你更多的思考，图画更具有渲染和说服力，图片的表达能力比文字强细节地方一定要画流程图，流程图画得好写代码才能轻松多做项目评审会，项目评审就是一个产品迭代，只是还没做出产品就已经有迭代了更多的倾听业务，系统设计是为了解决业务问题，是为业务服务的。你的系统可以不是完美的，但对于业务和用户一定是价值最大的
　　开发中线上系统异常处理要完善测试要完善，功能测试、性能测试都得做系统监控一定要完善，这个非常重要，没有监控和日志，出了问题就是两眼一抹黑项目排期一定要做好，一般项目开发都是多人协同开发，不能影响整体排期有风险及时暴露，这点很重要，很多人在项目中遇到问题或者风险点不敢暴露出来，害怕暴漏出来大家怀疑自己的能力，老板会给低绩效等。想着自己能很快解决，一般遇到风险都很难自己独自解决，不然也不会构成风险。暴露出来，大家群策群力，也不会拖延到项目排期。
　　上线后及时关注自己的服务监控指标，一般上线前都会经过测试、压测等，很多人就上线关注一会觉得没问题，就去庆功去了，别把庆功酒喝错了味道。业务是实时变化的，你要根据业务变化确定你的观察时机，正确观察几个周期无误后，才可以确定无误，以防年终奖没了。敏感业务都必须灰度很长时间做观测。听取反馈意见，收集反馈意见及时迭代自己的产品。挖掘潜在业务需求，提前布局迭代。总结
　　龙su是第一次做系统性设计，两个重要的点给大家说说
　　第一、想清楚在做，想清楚就是指前期需要花费大量的时间去做系统架构调研、讨论，细节构思清楚。我的这个系统设计花在调研、探讨、设计上的时间占据总时间的五分之二。构思和测试的时间是最长的，开发的时间是最短的。前期想的越清楚，开发难度越小。更有甚者，开发到中途发现设计不通，再开始返工。
　　第二、小步快跑，试错迭代，借用Pony老师的总结。现在互联网公司的项目都是要求很快速上线的，所以在开发上我们需要快速出产品，然后再不断迭代。不能一开始就做一个完美产品，这样用户是等不住的。
　　事实上不存在一开始做出来就是完美的产品，只有手机大量用户意见，不断迭代、不断改进、不断创新的产品才有可能是好产品。