主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
80后，IT宅男，全栈工程师。
开发者们的力量是无穷滴~欢迎一线的移动开发者们撰文分享你们的进阶、踩过的坑以及对热点技术的看法。一起关注 iOS、Android、跨平台、IoT、VR/AR等技术实践，投稿邮箱：。
NER（Named Entity Recognition，命名实体识别）又称作专名识别，是自然语言处理中常见的一项任务，使用的范围非常广。命名实体通常指的是文本中具有特别意义或者指代性非常强的实体，通常包括人名、地名、机构名、时间、专有名词等。NER系统就是从非结构化的文本中抽取出上述实体，并且可以按照业务需求识别出更多类别的实体，比如产品名称、型号、价格等。因此实体这个概念可以很广，只要是业务需要的特殊文本片段都可以称为实体。以下将详细介绍达观数据在文本语义理解过程中是如何构建中文NER系统的。（达观数据 高翔）2 NER问题分解
NER问题的目标是从文本抽取出特定需求实体的文本片段。针对这个任务，通常使用基于规则的方法和基于模型的方法。
2.1基于规则的方法
基于规则进行实体抽取是较容易想到的方式。针对有特殊上下文的实体，或实体本身有很多特征的文本，使用规则的方法简单且有效。比如，抽取文本中物品价格，如果文本中所有商品价格都是“数字+元”的形式，则可以通过正则表达式”\d*.?\d+元”进行抽取。但是如果待抽取文本中价格的表达方式多种多样，例如“一千八百万”、“伍佰贰拾圆”、“2000万元”，这个时候就要修改规则来满足所有可能的情况。随着语料数量的增加，面对的情况也越来越复杂，规则之间也可能发生冲突，整个系统也可能变得不可维护。因此基于规则的方式比较适合半结构化或比较规范的文本中的进行抽取任务，结合业务需求能够达到一定的效果。总结一下基于规则的实体抽取方式，优点：简单，快速；缺点：适用性差，维护成本高后期甚至不能维护。（达观数据 高翔）
2.2 基于模型的方法
从模型的角度来看，命名实体识别问题实际上是序列标注问题。序列标注问题指的是模型的输入是一个序列，包括文字、时间等，输出也是一个序列。针对输入序列的每一个单元，输出一个特定的标签。以中文分词任务进行举例，例如输入序列是一串文字：“我是中国人”，输出序列是一串标签：“SSBME”，其中“BMES”组成了一种中文分词的标签体系，B表示这个字是词的开始Begin，M表示词的中间Middle，E表示词的结尾End，S表示单字成词。因此我们可以根据输出序列“SSBME”进行解码，得到分词结果“我\是\中国人“。序列标注问题涵盖了自然语言处理中的很多任务，包括语音识别、中文分词、机器翻译、命名实体识别等，而常见的序列标注模型包括HMM，CRF，RNN等模型。
HMM（Hidden Markov Model，隐马尔可夫模型）是使用非常广泛经典的一个统计模型，作为一个生成式模型，HMM用来描述一个含有隐含未知参数的马尔可夫过程。简单来讲，HMM模型包括两个序列三个矩阵：观察序列、隐藏序列、初始状态概率矩阵、状态转移概率矩阵、发射概率矩阵。通常情况下，我们要根据观察序列和三个矩阵，来得到隐藏序列。
图1：HMM模型，其中X表示隐藏序列，y表示观察序列，a表示状态转移概率，b表示发射概率
以中文分词任务举例，使用“BMES”标签体系，HMM模型就是从切分好的语料中统计出初始状态概率矩阵、状态转移概率矩阵、发射概率矩阵这三个矩阵的概率参数。初始状态矩阵指的是序列第一个字符是BMES的概率，显然字符是M和E的概率为0。状态转移概率矩阵是BMES四种状态间转移的概率，显然B–&S，M–&S，M–&B等状态的转移概率为0。发射概率矩阵指的是一个字符是BMES四种状态其中一种的概率，比如“中–&B：0.3“、“中–&E：0.4“等。可以看到，HMM模型只需按照模型要求，统计出上述概率矩阵即可，因此HMM的优点是模型简单训练快，但因为马尔可夫假设的原因，模型效果相对较差。
CRF（Conditional random field，条件随机场）是一种判别式模型。条件随机场是给定随机变量X的情况下，随机变量Y的马尔科夫随机场。马尔科夫随机场是概率无向图模型，满足成对、局部及全局马尔可夫性。对于序列标注问题，一般使用线性链条件随机场。
图2：一种线性条件随机场
对于条件随机场的模型训练，通常使用基于BFGS、SGD等算法的优化算法，不同软件包的实现上也有所区别。理论上CRF算法性能要优于HMM，因为CRF可以使用更多的特征，但同时，特征选择对于模型的性能有一定的影响，除此之外，相对于HMM，CRF模型的训练也更加复杂，时间相对较长。
随着深度学习的兴起，RNN、LSTM、BILSTM等模型已经被证明在NLP任务上有着良好的表现。相比传统模型，RNN能够考虑长远的上下文信息，并且能够解决CRF特征选择的问题，可以将主要的精力花在网络设计和参数调优上，但RNN一般需要较大的训练数据，在小规模数据集上，CRF表现较好。在学术界，目前比较流行的做法是将BILISTM和CRF进行结合，借鉴两个模型各自的优点，来达到更好的效果。
图3：BILSTM+CRF标注模型
3基于CRF模型打造中文NER系统
上面介绍了用于序列标注不同模型的特点。虽然深度学习有着广阔的前景，并且在机器翻译等任务上表现优异，但对于序列标注任务而言，CRF模型老而弥坚且比较成熟，在工业界中被广泛使用，因此本章使用CRF模型打造一个中文NER系统。（达观数据 高翔）3.1 明确标注任务
前文讲过，NER可以根据业务需求标注各种不同类型的实体，因此首先要明确需要抽取的实体类型。一般通用场景下，最常提取的是时间、人物、地点及组织机构名，因此本任务提取TIME、PERSON、LOCATION、ORGANIZATION四种实体。
3.2 数据及工具准备
明确任务后就需要训练数据和模型工具。对于训练数据，我们使用经典的人民日报1998中文标注语料库，其中包括了分词和词性标注结果，下载地址为：。对于CRF，有很多开源的工具包可供选择，在此使用CRF++进行训练。CRF++官方主页为，包括下载及使用等说明。
3.3 数据预处理
人民日报1998语料库下载完毕后，解压打开“199801.txt”这个文件（注意编码转换成UTF-8），可以看到内容是由word/pos组成，中间以两个空格隔开。我们需要的提取的实体是时间、人名、地名、组织机构名，根据1998语料库的词性标记说明，对应的词性依次为t、nr、ns、nt。通过观察语料库数据，需要注意四点：1，1998语料库标注人名时，将姓和名分开标注，因此需要合并姓名；2，中括号括起来的几个词表示大粒度分词，表意能力更强，需要将括号内内容合并；3，时间合并，例如将”1997年/t
3月/t” 合并成”1997年3月/t”；4，全角字符统一转为半角字符，尤其是数字的表示。
通过脚本将语料库数据进行处理，处理前后的结果如图4和图5所示。
图4：人民日报1998标注语料数据处理前
图5：人民日报1998标注语料数据处理后
3.4 模型训练
根据我们的NER任务需求及CRF++的训练要求，模型训练需要4个步骤：1，确定标签体系；2，确定特征模板文件；3，处理训练数据文件；4，模型训练。（达观数据 高翔）3.4.1 确定标签体系
对于NER任务，常见的标签体系包括IO、BIO、BMEWO、BMEWO+。下面举例说明不同标签体系的区别。
表格1：不同标签体系的标注示例
大部分情况下，标签体系越复杂准确度也越高，但相应的训练时间也会增加。因此需要根据实际情况选择合适的标签体系。本文选择和分词系统类似的BMEWO标签体系。
3.4.2 特征模版设计
特征模版是一个文本文件，其内容如图6所示，其中每行表示一个特征。图6使用了unigram特征，并且仅以字符本身作为特征而不考虑其他特征。除当前字符外，还使用了其前后3个字，以及上下文的组合作为特征。CRF++会根据特征模版生成相关的特征函数。关于特征模版的详细解释可以查看官网文档，并且对于特征的选择和设计可以灵活配置，图6仅作为参考。
图6：特征模板设计
3.4.3 训练数据生成
CRF模型的训练数据是一行一个token，一句话由多行token组成。每一行可以分为多列，除最后一列外，其他列表示特征。本文所描述的NER系统，单字表示token，并且仅使用字符这一种特征，因此可以根据语料库中每个字在词中的位置和词性，以及所选的标签系统，生成CRF++的训练数据。生成的训练数据如图7所示。
图7：CRF++训练数据示例
3.4.4 模型训练
准备好特征模版和训练数据后就可以进行模型训练，如图8所示。使用crf_learn命令，指定模版文件、训练数据文件和输出模型文件就可以进行训练。参数-f 1表示过滤频次低于1的特征，在这里不进行特征过滤，-c 1.0用来调节CRFs的超参数，c值越大越容易过拟合。除此之外，还有-a等其他参数进行控制调整。图9展示了训练完毕的相关数据。
图8：CRF++训练过程
图9：CRF++训练结果
3.5 模型预测及使用
模型训练完毕后就可以进行预测。CRF++提供crf_test命令进行测试，我们使用文本“北京市委组织部长姜志刚调任宁夏副书记“进行测试，测试文件中每字一行，每句话使用空行隔开。测试结果如图10所示。
图10：CRF++测试结果
从图10的结果我们可以看到，CRF模型能够对输入文字序列输出相应的标签从而完成NER任务。在模型预测时，CRF++主要使用了维特比算法进行nbest输出。在模型训练时，可以指定-t参数输出文本格式的模型，方便debug或编写自己的模型加载及解码程序。
对于一个完整的NER过程，除了得到序列标签外，还要对标签序列进行解码得到最终的结果。CRF++同时提供了python接口，可以方便的在python 程序中进行模型的调用得到标签序列，然后通过标签解码得到最终的结果。图11展示了一个完整的NER预测结果。
图11：使用python代码进行NER的预测结果
图11展示了较好的结果，能够识别出诸如“北京小米科技有限责任公司”这样的组织机构名。通过使用1998年的数据识别出了2010年才成立的公司，这就是模型算法的力量。当然模型也有瑕疵，诸如“郁亮“、”海闻”这样的人名没有识别出来，这除了和模型特征选择相关外，也和语料库的规模和标注有关，因此语料库的建设和积累更加重要。（达观数据 高翔）
本文讲述了NER任务的基本概念及方法，并使用业界成熟的语料和工具开发了一个简单能work的基于CRF模型的中文NER系统，而实际提供线上服务的NER系统要比这个复杂的多。在自然语言处理的实际工作中，除了不同模型、算法、工具的使用和参数调优外，语料库的选择和积累也非常重要。对于中文文本语义分析技术，达观数据拥有多年的技术积累并紧跟行业潮流，对已有成熟技术进行深挖，对新兴技术进行研究集成。同时，针对不同行业及任务积累了丰富的文本语料，并源源不断的使用新数据对语料模型进行升级更新，保证分析结果的准确性和实时性，为客户提供高品质服务。（达观数据 高翔）作者简介
高翔，达观数据联合创始人，首席数据官联盟成员，达观数据前端项目组、文本语义理解组负责人，自然语言处理技术专家，上海交通大学通信专业硕士，曾代表达观数据参加2016青年互联网创业大赛并赢得全国总冠军荣誉、第五届中国创新创业大赛优秀企业奖、中国电子i+创新创效创意大赛总决赛一等奖。曾就职于腾讯文学，盛大文学，盛大创新院，负责文本阅读类产品、搜索引擎、文本挖掘及大数据调度系统的开发工作。在自然语言处理和机器学习等技术方向有着丰富的经验。一个社交App是如何构建高伸缩性的交互式系统
发表于 23:14|
摘要：本文旨在通过一个社交App的成长历程来从技术角度分析如何在云端构建大规模分布式系统，其中包括平台的可伸缩性、网络层面的扩展、数据和业务层面的扩展等。
CSDN移动将持续为您优选移动开发的精华内容，共同探讨移动开发的技术热点话题，涵盖移动应用、开发工具、移动游戏及引擎、智能硬件、物联网等方方面面，如果您有想分享的技术、观点，可通过电子邮件（tangxy#csdn.net，请把#改成@）投稿。第一时间掌握最新移动开发相关信息和技术，请关注mobilehub公众微信号（ID: mobilehub)。一个社交App需实现的功能用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等，需要提供的功能不胜枚举，所以从技术角度来说，开发者需要解决的问题也是异常复杂的。当一款社交App发布之初，用户访问量比较小，使用一台服务器就能够支撑全部的访问压力和数据存储需求，但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象，访问量和数据量在短时间内呈现爆发式增长，这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的，会直接导致服务器响应缓慢甚至超时，以及在高峰期时服务呈现瘫痪状态，使得后端的服务完全无法使用，用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。社交App最初部署的后端架构解析社交App在最初的时候，后端架构相对比较简单，最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡，后面放置3台应用服务器来负责处理所有业务上的请求，最后面搭建一台MySQL Database数据库。构建私有网络随着产品的不断迭代、用户数的持续增长、数据量的积累，App就需要改进自己的后端架构，即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络，将后续加入的用于运行内部服务的主机放置在私用网络中，可以有效地和云平台其他用户主机，在网络上实现100%二层隔离。主机对外开放的仅仅只有80端口，这样系统安全性上多了一层保障。在上面的架构图中，最前面的是防火墙，后面接负载均衡器，然后接路由器和私有网络，很多互联网应用都存在读多写少的情况，这个比例有时可以达到8:2，所以我们首先通过引入缓存分摊数据库读压力。其次，引入负载均衡器，替换最初架构中的nginx proxy，负责均衡器在这里其主要用于分发请求到后端多台应用服务器，，当其中一台应用服务器挂掉，负载均衡器可以进行自动隔离。业务分区与扩展App随着并发访问量和数据量不断增大，首先想到横向扩容Web服务。水平扩容业务服务器的前提是要保证每台服务器都是无状态的，将session信息下放到缓存或数据库中存储，保证请求被负载到任何一台服务器可以正常处理。从上图中看到，在前一步「构建私有网络」之后，增加了一个新的私有网络来扩展网络层，这里可以利用自有映像功能，将原有的应用服务器制作成模板，后续就可以基于这个模板快速启动新的主机。另外可以利用Auto-scaling（自动横向扩展）功能，根据后端服务器的负载请求，动态调整服务器的数量。一个社交应用的后端会提供很多服务请求接口，比如添加好友、刷新新鲜事、浏览页面等，可以通过日志分析每一个接口的耗时，将耗时长但非重要业务的请求分到单独的Web服务器上进行处理，从而给主Web服务器留出更多资源去处理关键业务的请求。面向服务的架构随着产品功能的不断迭代，业务代码会越来越复杂，出现故障的可能性也在加大，当一个局部功能出现问题时，都会影响整个服务的可用性。此时可以构建面向服务的架构，将一个完整且庞大的服务拆分为一个个的子服务，服务之间通过接口交互。如下图所示：社交App的服务被拆分成了四个子服务——新鲜事（News Feed）、用户资料（Profile）、广告（Ads）和探索（Explore），不同的服务之间通过消息通信框架（例如ZeroMQ）来进行交互。把一个大服务拆分为几个小的子服务的好处不言而喻，主要是：故障隔离：子服务出现故障不会影响全局，比如广告业务出现问题并不会让整个App不能使用，依然可以查看新鲜事等；独立扩展：每一个被拆分出的子服务有着不同的访问压力，比如新鲜事的调用相比一些二级页面的用户资料要高很多，所以前者会被分配更多的Web 服务器；独立部署：一个大服务的配置因功能过多会异常复杂，一旦被拆分就可根据不同的特性需求定制配置项，从而提高可管理性；团队协作开发：开发者都有着自己精通的方向，从而提高开发效率；抽象出数据访问：在后续进行数据层面（数据库、缓存）扩展时，可通过修改子服务的Data Service，实现对下层数据的透明。数据库Replication业务增长也会给数据库带来诸多问题，当最初架构中单台数据库（数据库同时提供读和写）不足已支撑起App访问压力时，首先需要做数据副本Replication。市面上常见的MySQL、MongoDB等数据库都提供Replication功能，以MySQL为例，从高层来看，Replication可分成三步：Master将改变记录到二进制日志（binary log）中（这些记录叫做二进制日志事件，binary log events）；Slave将Master的binary log events拷贝到它的中继日志（relay log）；Slave重做中继日志中的事件，将改变反映它自己的数据。具体实现该过程的第一部分就是Master记录二进制日志。在每个事务更新数据完成之前，Master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志，即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后，Master通知存储引擎提交事务。下一步就是Slave将Master的binary log拷贝到它自己的中继日志。首先，Slave开始一个工作线程——I/O线程。I/O线程在Master上打开一个普通的连接，然后开始binlog dump process。Binlog dump process从Master的二进制日志中读取事件，如果已经跟上Master，它会睡眠并等待Master产生新的事件。I/O线程将这些事件写入中继日志。SQL slave thread处理该过程的最后一步。SQL线程从中继日志读取事件，更新Slave的数据，使其与Master中的数据一致。只要该线程与I/O线程保持一致，中继日志通常会位于OS的缓存中，所以中继日志的开销很小。此外，在Master中也有一个工作线程：和其它MySQL的连接一样，Slave在Master中打开一个连接也会使得Master开始一个线程。复制过程有一个很重要的限制——复制在Slave上是串行化的，也就是说Master上的并行更新操作不能在Slave上并行操作。对于云计算使用者来说，只需要知道数据库的IP和端口即可进行使用。具体实现见下图：第一步要做的是扩充Slave，将单机Master变成Master+3台Slave的架构，而在其中的Slave上搭建一个内网的负载均衡器（Load Balancer），对于最上层的Data Service来说，只要配置一个MySQL Master节点和一个LB节点即可，今后因业务变化进行增减Slave对上层来说完全是透明的。此做法可以带来两个好处，第一是提高可用性，若是一台Master出现错误，则可以提升某一台的Slave作为Master继续提供服务，从而保证数据可用性；第二个是分摊读压力，对于一个社交App来说，读写分离是在数据层优化第一步要做的事情，利用上面的架构可以很轻易地做到将读的请求分担到MySQL Slave上进行查询，而写留给Master。但是读写分离时会有数据库一致性的问题，即在数据写至Master之后同步到Slave有一个延迟的时间，对于社交应用来说，这是可以接受的，只要保证数据的最终一致性即可。在上图的最下面有一个Snapshot，即定期对数据进行冷备份，这不同于单纯对MySQL Master进行复制的Slave，因为线上bug或误操作会删除Master上的数据，这时会立即同步到slave上造成数据丢失这时冷备份Snapshot就会起到数据保护作用。运行过程中肯定需要监控，用户可以利用Linux上的工具进行统计分析top / iotop / df / free / netstat等工具去监控系统里的各个服务和组件是否正常运行，以及通过日志的信息（http access log / application log / database slow log ）分析各个服务的性能瓶颈。数据分区与扩容下一步业务的调整要进行数据库的分区和扩容。第一，构建缓存集群，在开始的架构中引用了Memcached缓存，是单机数据库缓存。当数据量增长，，需要把数据分散到多台缓存服务器上，常用的是HashRing算法，好处在于不管是添加结点还是删除结点时，只会使得少部分数据失效。还可以引用NoSQL数据库，这里用到了Redis把社交数据里对于关系要求不强但对查询效率要求很高的数据从MySQL里拿到Redis里存。Redis尤其适合存储列表类数据，比如好友关系列表、排行榜数据等。除此以外可以考虑做数据分区对于MySQL第一步是垂直拆分，把原来单独的数据库按照功能模块分别拆分成：好友新鲜事、用户资料、广告数据以及探索数据。对于Redis也同样，将原来的单台Redis按照功能模块拆成四个，分别为：排行榜数据、好友、广告数据、探索数据。接下来会遇到的瓶颈是单表过大的问题，这时候我们需要做水平拆分——把一个表拆分成多个表，需要选取一个分区Key，比如对用户表做拆分时，通常选取User ID。分区key的选择主要是看所有的查询语句频繁使用哪个查询字段，就选择那个字段作为分区key这样能保证大部分的查询可以落在单个数据表上，少量没有带分区Key的查询语句，可能要遍历一遍所有切分后的数据表。构建完整的测试环境构建完整测试服务器时需要创建新的路由器和私有网络、独立的网络环境和带宽资源、内网GRE隧道打通路由器、VPN拨入网络和SSH密钥管理。这个过程你可以创建一个包含所有系统服务的all-in-one的环境，将其制作成自有映像。如果后续你的团队来新的人，需要独立的完整开发环境，只需基于自有镜像快速创建主机即可；还可以利用User Data定制化功能，在主机启动执行一段你上传的脚本，来初始化环境。你可以将这两个功能结合起来用，把所有你所需要用的服务全部安装部署完毕后做成映像，并用User Data脚本从代码库里更新代码。因为代码的变动相对于环境的更新更加频繁，不可能每次代码的更新都要构建一个新的自有镜像。通过这种方式构建起一个完整的测试服务器，让每个工程师都可以有自己独立的测试服务器。在App发布上线时需要连到线上环境怎么办？这两个网络本身完全100%隔离，可利用GRE隧道的功能，把两个路由器打通，实现测试环境网络和线上生产环境网络的完全连通。多机房部署与混合组网为了让后端架构更可靠和业务更稳定，就需要实施多机房部署和混合组网。具体原因有以下三点：异地容灾：在复杂的网络环境下，机房可能会出现网络状况，导致一些比较关键性的业务的可用性降低，备份机房后可保证服务不会出现明显的长时间中断；负载分摊：单独一个机房可能不足以支撑全部的请求，这时可以把一部分的请求压力分担到另一个机房；加速区域访问：在国内网络环境下，南方和北方相互之间网络访问时有较高的延迟。通过做多机房部署实现加速区域用户的访问。如上所示，有三个机房，中间是QingCloud北京1区机房，负责主营业务。左边是亚太1区机房，主要服务亚太和海外的客户。这两个机房都使用了QingCloud私有网络部署，利用路由器，通过GRE隧道或者IPsec加密隧道的方式进行互通。如果对数据传输过程的安全性要求较高，可以用IPsec的方式把两个机房相互打通，这时的访问只能通过内网IP进行访问。右边是办公室机房，工程师在这个环境下进行开发。在实现混合组网时，只要机房路由器或者网宽设备支持标准的GRE隧道协议、IP隧道协议，就可以将传统物理世界的机房与路由器连通，并最终打通公有云环境。多机房部署通常见的方案有这些：异地冷备份把主机房全套业务在异地重新构建一遍，且不需要提供线上服务，只有在主机房出现故障的时候才切换到备用机房，部署相对要简单一些。但有两方面缺点，一是成本比较高，需要双倍的费用且只是用来做冷备份，平时完全用不上；另外，当主机房突然挂掉时，备用机房再起动起来提供服务，数据需要预热，这是非常缓慢的过程，可能会出现服务响应慢，甚至不能正常提供服务。异地多活从易到难有三阶段：第一，反向代理，用户请求到第二个机房，但不做任何处理被转向第一个机房这样会对两地的延时有一定的要求。第二，在第二个机房部署应用服务器和缓存，大部分的数据请求可以从缓存中读取，不用进行跨机房请求，但当缓存失效时，依然落到第一个机房的数据库去查询。所以，这个方式不太彻底；第三，全套服务的部署，包括HTTP服务器、业务服务器、缓存和数据库的 slave。此方式使得进入第二个机房的请求，只需要在机房内就可以完成请求处理，速度更快，但会遇到数据一致性和缓存一致性的问题，针对这点也会有一些解决方法。除了数据同步过程中的不一致问题，还需要面对缓存。好的系统架构不是设计出来的，而是进化而来的构建稳定可靠的业务系统需要注意以下这些：分析用户行为，理解你的业务，如社交、电商、视频；不同的业务有不同的行业属性和特点，对于社交来讲，比较典型的特点是数据量庞大、数据查询维度多，比如查询6月11日-7月15日在xx咖啡厅我所有好友里拍过照片的人，查询条件包括好友维度、照片维度、地点维度、隐私状态维度等，这时就需要合理的做数据层面的扩展。电商的特点是定期举办大促销活动，届时会需要大量的计算资源、应用服务器来扛流量峰值，此时可利用云计算平台的弹性实现快速扩展业务，而在自己业务压力、促销来临时调用API接口，及AutoScaling扩展后端计算资源。视频业务有非常明显的流量高峰期和低峰期，流量高峰期通常是白天或者大家晚上下班回家那段时间，晚上2点到早上6点是流量非常低的时候，可利用云计算弹性优势，来调用API方式调整业务带宽资源，从而达到节省成本目的。合理规划系统，预估系统容量，如 10w / 100w / 1000w PV（DAU）：不同的系统容量有可能对应不同架构的部署方式，找到最适合自己的那一个；系统是可横向扩展的 scalable；不遗余力地解决单点问题；为出错而设计design for failure：App的后端架构在开发支出就要为可能出现的各种问题进行准备，比如异地备份等；设计面向服务的架构，拆分子系统，API交互，异步处理；构建无处不在的缓存：页面缓存、接口缓存、对象缓存、数据库缓存；避免过度设计，好的系统架构不是设计出来的，而是进化而来的。本文整理自：【】（点击链接，观看视频），演讲PPT&&。作者简介：王煜，QingCloud研发工程师，负责对象存储系统的研发，对Linux操作系统、计算机网络、分布式系统、云计算等领域有深入的研究。原街旁创始成员，基础架构负责人。
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章