最新推荐方案架构知乎优秀word范文 13页.docx
《最新推荐方案架构知乎优秀word范文 13页.docx》由会员分享，可在线阅读，更多相关《最新推荐方案架构知乎优秀word范文 13页.docx（12页珍藏版）》请在冰豆网上搜索。
最新推荐方案架构知乎优秀word范文13页
本文部分内容来自网络整理，本司不为其真实性负责，如有异议或侵权请及时联系，本司将立即删除！
==本文为word格式，下载后可方便编辑和修改！
==
方案架构知乎
篇一：
知乎架构变迁史：
从0到100
也许很多人还不知道，知乎在规模上是仅次于XX贴吧和豆瓣的中文互联网最大的UGC（用户生成内容）社区。
知乎创业三年来，从0开始，到现在已经有了100多台服务器。
目前知乎的注册用户超过了1100万，每个月有超过8000万人使用；网站每个月的PV超过2.2亿，差不多每秒钟的动态请求超过2500。
在ArchSummit北京201X大会上，知乎联合创始人兼CTO李申申带来了知乎创业三年多来的首次全面技术分享（幻灯片下载）。
本文系根据演讲内容整理而成。
初期架构选型
在201X年10月真正开始动手做知乎这个产品时，包含李申申在内，最初只有两位工程师；到201X年12月份上线时，工程师是四个。
知乎的主力开发语言是Python。
因为Python简单且强大，能够快速上手，开发效率高，而且社区活跃，团队成员也比较喜欢。
知乎使用的是Tornado框架。
因为它支持异步，很适合做实时Comet应用，而且简单轻量，学习成本低，再就是有FriendFeed的成熟案例，Facebook的社区支持。
知乎的产品有个特性，就是希望跟浏览器端建立一个长连接，便于实时推送Feed和通知，所以Tornado比较合适。
最初整个团队的精力全部放在产品功能的开发上，而其他方面，基本上能节约时间、能省的都用最简单的方法来解决，当然这在后期也带来了一些问题。
最初的想法是用云主机，节省成本。
知乎的第一台服务器是512MB内存的Linode主机。
但是网站上线后，内测受欢迎程度超出预期，很多用户反馈网站很慢。
跨国网络延迟比想象的要大，特别是国内的网络不均衡，全国各地用户访问的情况都不太一样。
这个问题，再加上当时要做域名备案，知乎又回到了自己买机器找机房的老路上。
买了机器、找了机房之后又遇到了新的问题，服务经常宕掉。
当时服务商的机器内存总是出问题，动不动就重启。
终于有一次机器宕掉起不来了，这时知乎就做了Web和数据库的高可用。
创业就是这样一个情况，永远不知道明早醒来的时候会面临什么样的问题。
这是当时那个阶段的架构图，Web和数据库都做了主从。
当时的图片服务托管在又拍云上。
除了主从，为了性能更好还做了读写分离。
为解决同步问题，又添加了一个服务器来跑离线
脚本，避免对线上服务造成响应延迟。
另外，为改进内网的吞吐量延迟，还更换了设备，使整个内网的吞吐量翻了20倍。
在201X年上半年时，知乎对Redis已经很依赖。
除了最开始的队列、搜索在用，后来像Cache也开始使用，单机存储成为瓶颈，所以引入了分片，同时做了一致性。
知乎团队是一个很相信工具的团队，相信工具可以提升效率。
工具其实是一个过程，工具并没有所谓的最好的工具，只有最适合的工具。
而且它是在整个过程中，随着整个状态的变化、环境的变化在不断发生变化的。
知乎自己开发或使用过的工具包括Profiling（函数级追踪请求，分析调优）、Werkzeug（方便调试的工具）、Puppet（配置管理）和Shipit（一键上线或回滚）等。
日志系统
知乎最初是邀请制的，201X年下半年，知乎上线了申请注册，没有邀请码的用户也可以通过填写一些资料申请注册知乎。
用户量又上了一个台阶，这时就有了一些发广告的账户，需要扫除广告。
日志系统的需求提上日程。
这个日志系统必须支持分布式收集、集中存储、实时、可订阅和简单等特性。
当时调研了一些开源系统，比如Scribe总体不错，但是不支持订阅。
Kafka是Scala开发的，但是团队在Scala方面积累较少，Flume也是类似，而且比较重。
所以开发团队选择了自己开发一个日志系统——Kids（KidsIsDataStream）。
顾名思义，Kids是用来汇集各种数据流的。
Kids参考了Scribe的思路。
Kdis在每台服务器上可以配置成Agent或Server。
Agent直接接受来自应用的消息，把消息汇集之后，可以打给下一个Agent或者直接打给中心Server。
订阅日志时，可以从Server上获取，也可以从中心节点的一些Agent上获取。
具体细节如下图所示：
知乎还基于Kids做了一个Web小工具（KidsExplorer），支持实时看线上日志，现在已经成为调试线上问题最主要的工具。
Kids已经开源，放到了Github上。
事件驱动的架构
知乎这个产品有一个特点，最早在添加一个答案后，后续的操作其实只有更新通知、更新动态。
但是随着整个功能的增加，又多出了一些更新索引、更新计数、内容审查等操作，后续操作五花八门。
如果按照传统方式，维护逻辑会越来越庞大，维护性也会非常差。
这种场景很适合事件驱动方式，所以开发团队对整个架构做了调整，做了事件驱动的架构。
这时首先需要的是一个消息队列，它应该可以获取到各种各样的事件，而且对一致性有很高的要求。
针对这个需求，知乎开发了一个叫Sink的小工具。
它拿到消息后，先做本地的保存、持久化，然后再把消息分发出去。
如果那台机器挂掉了，重启时可以完整恢复，确保消息不会丢失。
然后它通过Miller开发框架，把消息放到任务队列。
Sink更像是串行消息订阅服务，但任务需要并行化处理，Beanstalkd就派上了用场，由其对任务进行全周期管理。
架构如下图所示：
举例而言，如果现在有用户回答了问题，首先系统会把问题写到MySQL里面，把消息塞到Sink，然后把问题返回给用户。
Sink通过Miller把任务发给Beanstalkd，Worker自己可以找到任务并处理。
最开始上线时，每秒钟有10个消息，然后有70个任务产生。
现在每秒钟有100个事件，有1500个任务产生，就是通过现在的事件驱动架构支撑的。
页面渲染优化
知乎在201X年时每天有上百万的PV，页面渲染其实是计算密集型的，另外因为要获取数据，所以也有IO密集型的特点。
这时开发团队就对页面进行了组件化，还升级了数据获取机制。
知乎按照整个页面组件树的结构，自上而下分层地获取数据，当上层的数据已经获取了，下层的数据就不需要再下去了，有几层基本上就有几次数据获取。
结合这个思路，知乎自己做了一套模板渲染开发框架——ZhihuNode。
经历了一系列改进之后，页面的性能大幅度提升。
问题页面从500ms减少到150ms，Feed页面从1s减少到600ms。
面向服务的架构（SOA）
随着知乎的功能越来越庞杂，整个系统也越来越大。
知乎是怎么做的服务化呢？
首先需要一个最基本的RPC框架，RPC框架也经历了好几版演进。
第一版是Wish，它是一个严格定义序列化的模型。
传输层用到了STP，这是自己写的很简单的传输协议，跑在TCP上。
一开始用的还不错，因为一开始只写了一两个服务。
但是随着服务增多，一些问题开始出现，首先是ProtocolBuffer会生成一些描述代码，很冗长，放到整个库里显得很丑陋。
另外严格的定义使其不便使用。
这时有位工程师开发了新的RPC
框架——Snow。
它使用简单的JSON做数据序列化。
但是松散的数据定义面对的问题是，比如说服务要去升级，要改写数据结构，很难知道有哪几个服务在使用，也很难通知它们，往往错误就发生了。
于是又出了第三个RPC框架，写RPC框架的工程师，希望结合前面两个框架的特点，首先保持Snow简单，其次需要相对严格的序列化协议。
这一版本引入了ApacheAvro。
同时加入了特别的机制，在传输层和序列化协议这一层都做成了可插拔的方式，既可以用JSON，也可以用Avro，传输层可以用STP，也可以用二进制协议。
再就是搭了一个服务注册发现，只需要简单的定义服务的名字就可以找到服务在哪台机器上。
同时，知乎也有相应的调优的工具，基于Zipkin开发了自己的Tracing系统。
按照调用关系，知乎的服务分成了3层：
聚合层、内容层和基础层。
按属性又可以分成3类：
数据服务、逻辑服务和通道服务。
数据服务主要是一些要做特殊数据类型的存储，比如图片服务。
逻辑服务更多的是CPU密集、计算密集的操作，比如答案格式的定义、解析等。
通道服务的特点是没有存储，更多是做一个转发，比如说Sink。
这是引入服务化之后整体的架构。
篇二：
拟上市公司股权结构顶层设计方案
新三板/IPO：
拟上市公司股权结构顶层设计方案
源自：
知乎专栏
转自：
弘仁投资
最近碰见几个企业的实际控制人、控股股东都在问一个问题，是直接持股上市好呢，还是先设一个控股公司再持股拟上市公司上市好呢，正好前面也做过一些分析，拿出来分享一下。
或者
自然人直接持股与控股公司持股只是持股方式不同而已，不影响控股股东的合计持股比例。
但是基于以下原因，一般而言，我们是建议实际控制人最好成立一个控股公司对拟上市公司持股，然后再去上市，当然可以留少量一部分用于直接持股。
一、集中股权，提高对上市公司的控制力，提高在并购重组过程中以股权作为支付方式能力。
看两个例子一目了然。
某上市公司（信息来源于招股书）
公司控股股东、董事长钱忠良为实际制人。
管理团队主要成员雷斌、汪建军、卜文海、王海滨、尹显庸、杨燎、张军、李远恩、张曹、龚崇明、王浩、姚兵、田琳、杨勇、黄文勇、李成静、贾云刚、冯嫔、盛科、叶娟、蓝灵以及王定英、睢
迎春共23人为一致行动人。
股权如此分散，首发上市后控股股东、实际控制人钱忠良的股份更被稀释。
按照201X年11月26日的收盘价计算，钱忠良的股份市值仅为3.5亿元左右，也就是说目前只要收购一个标的以股份支付的话，价值超过3.5个亿其控股地位就不保（虽然有一致行动协议，但是多麻烦啊）。
如果将这些一致行动人全部放在一个公司然后对上市公司持股，那么控股股东的持股比例就会高很多，对外并购股权支付的空间就会大很多。
另一上市公司
公司控股股东为长江润发集团，实际控制人为郁全和、郁霞秋、邱其琴及黄忠和四位自然人。
其中，郁霞秋为郁全和之女，邱其琴为郁全和之堂侄女婿，黄忠和为郁全和之妻侄。
要是他们都非得要直接持有股份公司的股份，四个人合起来也就是16%左右股份，淹没在众多自然人股东中，根本谈不上控制长江润发。
二、简化上市公司信息决策流程，不用等到在上市公司的股东大会上再进行决策。
由于通过将自然人股东放在控股公司层面，在股份公司进行重大决策时，可以先在控股公司层面通过法定程序将不同意见排除，便于股份公司重大决策的进行。
比如在改制重组、IPO等会议时，若是持有控股股东极小股权的股东不同意，那么在控股股东层面通过公司法对有限公司的决策权限的界定，可以形成最终的决定，保证股份公司的重大事项继续进行。
而若是股份公司层面，在改制重组、IPO等重大事项中哪怕有一个小股东不同意签字，在实际操作中也会导致该事项进展暂缓，解决完他们的诉求才能继续。
再说一个比较明显的事情，若公司股东是几十个自然人，开一个必须到齐的股东大会非常难，要拿到每个人的亲笔签字更是更麻烦，尤其是有一些仅仅是财务投资人，不是公司员工的情况下。
而若是能尽量将股权收拢，只需要法人股东的股东会决议加上公章就可以了，就简单多了。
三、承接上市主体中目前不宜上市或者目前尚不成熟的业务，待时机成熟后单独上市（国内或者国外、A股或者新三板）或者以定向增发方式注入上市公司。
案例
万达电影院线股份有限公司将在A股上市（已经通过发审会）；大连万达商业地产股份有限公司将在港股IPO。
可以预见的是，上市成功后，关于电影发行等文化娱乐类资产将会单独上市或者注入万达电影院线，地产类资产应该将逐步注入万达商业地产。
案例
曾经折戟于财务专项核查的广汇汽车，目前准备在港股IPO，与广汇能源（600256）同隶属于广汇集团。
案例
物美控股（原北京物美投资集团有限公司）旗下具有两大上市平台，即香港上市的物美商业（01025）及国内A股上市的新华百货（600758）。
四、调整控股公司股权比较方便，便于对拟上市公司股权进行管理。
由于股份公司发起人在一年内不准转让。
若将可能进行调整的投资者（比如说需要进行业绩考核的管理层，需要针对其带来资源效果对其股权进行调整的投资者）纳入控股公司而不是股份公司，可以在控股公司层面对其股份进行调整，从而间接达到调整股权结构的目的。
这种方式在上市前和上市后均可以实现。
最典型就是股权激励，对管理层的股份进行调整，在拟上市公司层面进行调整时，既需要考虑被调整对象是否同意，还要考虑调整的价格，且控股股东没有优先购买权。
若是放在控股公司那么受到的约束就相对会少一些。
五、对上市公司（或者拟上市公司）的债务融资提供抵押、担保，降低融资成本。
由于控股公司可以合并上市公司报表及其他产业的报表，很多控股上市均开展了房地产业务，其资金实力一般强于上市公司，受到银行认可的程度较高。
公司在上市公司银行借款、发行债券等过程中，提供相应的担保，提高上市公司债项的信用等级，降低融资成本。
随时准备承接上市公司的非优质资产，为上市公司的未来发展协调资源
控股公司可以承接上市公司在未来经营过程中形成的一些盈利能力不强的项目，保证上市公司资产的优质性。
同时可以为股份公司的现在和未来发展协调各种战略资源，安排不宜在上市公司层面安排的利益。
案例可见湘鄂情。
六、控股公司可以在达到一定资产规模之后，以发行企业债、发行中期票据获得资金开展一些不宜在上市公司内部开展的业务（比如房地产）。
或者通过股权质押、出售股票、吸引外部投资者增资的方式对实际控制人想重点发展的产业进行培育。
例如：
篇三：
产品架构设计
产品的架构分为五个层面：
?
战略层
?
范围层
?
结构层
?
框架层
?
表现层
这五个层面，每一个层面都由它下面的那个层面来决定。
从战略层到表现层，也就是从抽象到具体的过程。
这五个层面并不是独立开来的，也就是说并不是要完全做好“底下一层”才能做“上面一层”，而是让每一层面的工作在下一层面可以结束之前完成。
如下图所示：
在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。
（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。
在每一个层面我们都会根据竞争对手的情况和在业内已经过用户检验并得到良好结果的方面，做出符合我们自身情况的决策。
（这里就是大家常常所说的“竞品分析”和“不重复发明轮子”，其中重点是你要真正的看”懂“竞品，找出优质并符合自身的轮子）。
此外，早期的互联网产品基本都是信息型的产品，而随着互联网技术的告诉发展以及人们对互联网产品的需求越来越广，越来越高。
互联网产品加入了越来越多的功能，这就有了我们平常所说的功能型产品。
但是目前大多数互联网产品都不是处于信息型或功能型单一的方面，而是”混合型“的产品。
（你能说新闻类产品就是单纯的信息型产品吗？
或者你能说搜索引擎产品就是简单的功能型产品吗？
）
但是，我们在做产品讨论、沟通或决策的时候。
我们会发现有人从内容需求、信息架构、导航设计这条线去讨论，而有些人会以功能规格、交互设计、界面设计这条思路去阐述。
这样往往将这两个方面混在一起讨论，从而产生模棱两可的结果，谁也说服不了谁。
其实原因就是你们说的不在一个维度上，自然谁也无法说服谁。
所以我们姑且将两个分开讨论。
也就是下图的分布：
下面分别在这五个层面展开：
战略层：
这是最底的一层，这一层可以说展现了我们产品的灵魂。
在这一次我们需要回答两个重要的问题：
?
我们要通过这个产品得到什么？
产品目标
?
我们的用户要通过这个产品得到什么？
用户需求
这两个问题必须在范围层结束之前解决，不然你的产品从开始就已经偏离了主线，我想这个产品离着失败也就不远了。
在这一层，我提供一个方法论：
可以从四个方向去想产品：
?
第一点：
蓝海市场，我们发现了强需求（占先机）
?
第二点：
红海市场，我们有天然的优势（占天赋）
?
第三点：
蓝海市场+当前弱需求（超前占位）
?
第四点：
红海市场+自身无优势（被迫阻击）
如果做前两点的产品，可以说是幸运的，也是相对容易做出成绩的，这里你的天赋可以说是技术、平台等等。
如果是蓝海市场而且目前是弱需求，可以这么说这个产品超前了，但不是说天马行空，在目前来说只是弱需求。
（比如从目前来说，可穿戴设备领域，智能硬件领域。
）如果是红海市场而且没有优势，但是如果不做原本业务就会受到影响，甚至倾覆或者对未来的业务拓展造成了很大的阻碍。
那么，硬着头皮也要做。
（比如阿里巴巴做来往，以及支付宝改版中的9.0版本）在这一层还要考虑的是在用户头脑的品牌形象，这是很多大公司在拓展新业务的时候，需要想到的事情。
因为当一个品牌在人们心中根深蒂固的时候，往往会产生下意识的映射。
这样对你的新产品的推广起不到好的作用，因为人们会觉得你不专业。
此外，在这一层一定要将“用户”搞清楚：
?
“用户是谁”
?
“用户的需求是什么（根本需求）”
?
“用户细分”
?
”创建人物角色“
最后，战略是可以演变和改变的，它贯穿于一个产品的始终，它是产品的初衷，也就是上面所说的产品的灵魂。
范围层：
这个层面上，我们要回答这个问题：
我们要开发的是什么？
?
从功能型角度来考虑，我们需要考虑功能规格。
?
从信息型角度来考虑，我们需要考虑内容需求。
这两者是血肉关系，你中有我，我中有你。
正如”知乎“是一个UGC的产品，其中一定要有一个内容管理系统，在系统中要有编辑，审核等功能。
在功能需求方面，我们往往会会用到一个词-”场景“，他的意思是通过想象我们的用户将会经历什么样的过程，我们帮助他顺利的完成这个过程的潜在需求。
在这个层面上，我们要写一个熟悉的文档，叫prd文档。
关于prd文档怎么写好，这里不再赘述。
结构层：
在这个层面上，逐渐由抽象向具体转变。
在这里最关键的就是”理解用户“-理解用户的工作方式、行为和思考方式。
将这些转化为知识，注入到我们的产品中。
在交互设计方面，要注重逻辑，模型。
在信息架构方面，要注重内容的管理，分类和顺序。
框架层：
?
界面设计：
比如说用什么控件表现，哪块需要重点呈现（大大的按钮）。
做界面设计时，要遵循大多数人原则。
建议大家去看看人机界面相关
的书籍。
?
导航设计：
这个要解决的问题就是要清楚的告诉用户，”你在哪“，”你能去哪“。
”你怎么去“。
（现在大家都在用搜索啦，首页顶部都
会有一个大大的搜索框）
在这里提一句，在这里还有一个老朋友就是，我们要做线框图。
（建议不加多余色彩，不然容易被吐槽，用黑灰色）
表现层：
这一层也就是感知设计。
大部分是视觉方面的，也会有听觉、触觉等方面（比如声音、震动）。
这个也就是我们产品的”颜值“。
这个方面产品经理要多与我们
的设计师沟通啦，充分激发设计师的想象力。
这就是平常我们所说的-”性感的产品“。
本文的大体框架来自：
用户体验要素（豆瓣），向大家推荐本书。
其实产品架构嘛，其实就像搭建一座楼一样，需要哪些组成部分，各方面需要投入多少注意什么，才能保证这个楼的稳固，这个我想和技术架构的思路是一样的，但是内容却基本不同。
所以如果要有产品架构的能力，就得站高，你眼中看到的不是一个表单，不是一次交互，不是一个功能，而是你要达到一个目标，你需要的整个的产品循环。
比如你要搭建一套UGC平台，为了能够运转起来，你需要用户进入模块，包括什么欢迎页面、登录注册甚至邀请流程，需要有新手引导等等，你需要有发布内容流程，这个就会细到各种交互表达设计等待的，然后内容组织，用分类还是标签还是纯基于人这个节点什么的，然后浏览发现利用的流程，比如搜索呀，推荐呀，广场呀按照需求考虑用什么，然后用户激励需要贯穿，比如用什么方式让用户交互起来，用什么方式来表达用户的贡献，操作、消息是否通畅什么的~可能还需要考虑反作弊模块，数据挖掘的模块等等，根据需求来吧~
上面所说可以架构一个产品的主要模块，但是还不够，产品需要有血有肉还得和运营配合起来，那又大了，内容和用户的控制模块，对外输出内容引入用户的渠道等等。
形成一幅更完善的产品图谱，这样就能知道哪些模块互相影响，哪些地方出问题了，哪些地方是短板，哪些地方不足影响了最终的产品目标等等。
这是我理解的产品结构。
篇四：
之乎推广策略研究与分析
江工业大
学院：
人文学院
专业：
广告1101
姓名：
沈丽艳
学号：
２０１１０８２８０１１６学浙知乎推广策略的研究与分析
知乎推广策略的研究与分析
【摘要】伴随着社交网站、社会问答网站的快速发展，如何让自己的网站产品在激烈的互联网市场中占据一席之地，成了企业开展网络营销必须面临、解决的问题。
一个网站产品是否成功关键在于它的运营模式，而运营的核心是推广。
因此本论文以知乎网的推广策略为研究对象，从推广前提（包括网站定位、用户需求、产品功能设计、内容与服务）和正式推广两个角度进行研究探讨，并对它的不足提出改善性建议，同时在之乎传统的推广方式基础上提出扩大知名度的其他推广方法。
【关键词】知乎；推广
一绪论
第一节：
研究背景-------------------------------------------------3
第二节：
研究动机-------------------------------------------------3
二文献探讨
第一节：
网站推广定义---------------------------------------------4
第二节：
网站推广前提---------------------------------------------4
第二节：
网站推广方法---------------------------------------------4
三正文--------------------------------------------------------------------5
四结论--------------------------------------------------------------------7
一绪论
第一节：
研究背景
根据中国互联网信息中心CNNIC发布的第32次调查报告显示，截至201X年6月底，我国网民规模达5.91亿，互联网普及率达到44.1%。
由此可见，这个蓬勃发展的网络市场蕴含着巨大的商业开发资源，但同时又充满了挑战与威胁。
仅中国的知名社会化问答网站来讲，就有略晓、XX新知、问对网、好问好答、即问即答等等，这些作为一个公共知识平台的问答类SNS网站在过去两年里都如雨后春笋般涌现出来，通过引入用户之间的关系来发现问题、筛选答案，获得了多数用户的喜爱。
然而，网络惊人的发展速度也使得该市场由蓝海逐渐向红海市场过渡，而知乎是在201X年一月底上线的，因此它在时间上并无优势可言。
但从用户本身、知识盲区、名人效应、内容质量方面来说，对于提供高质量内容的知乎又有着潜在的市场机遇。
首先用户具有分享的欲望，他们渴望通过自身的广博知识建立个人威望。
其次知识是无限的，每一个用户都会存在一定的知识盲区，追求高质量的答案是用户的需求，而搜索引擎的答案不一定高质量，但知乎却是汇集一批专家来答用户所问，自然会受喜爱。
同时众多互联网业界领袖也纷纷入驻知乎，例如创新工场董事长兼CEO李开复、著名天使投资人蔡文胜，他们会把自己在知乎上一些有价值的回答作为博客文章、微博发布，使得大多数人关注、转载，这对知乎的推广有很大作用。
最后涉及的是许多社交工具主要用于信息传递与分享，但是信息量繁杂，高质量信息较难发掘，而随着知识进步，高质量内容一定是未来发展趋势。
第二节：
研究动机
社会问答网站是在最近几年才开始兴起的，市场尚未形成固定格局，机遇与挑战并存。
升级会员 