服务器从0到200，一个创业公司的架构生长史

贝聊建立于2013年，是中国幼儿园家长工作平台，努力于经过互联网产物及定制化处理计划，帮助幼儿园处理展现、告诉、相同等家长工作中的痛点，促进故里关系和谐。贝聊是威创股份（A股幼教第一股）、清华启发、网易联手投资的唯一品牌。在短短几年内，用户范围敏捷到达万万级别，每年DAU均呈倍数级增加。

面临如此快速的成长，原本的技术架构很难支持越来越复杂的营业场景，在系统可用性以及稳定性方面，都给贝聊技术团队带来了很大的压力。是以，若何针对当前需求，挑选合适的技术架构，保证架构平滑演进，值得我们深入思考。

贝聊架构整体履历了三次严重过程，由几台办事器搭建的单体架构到今朝的几百台散布式摆设架构，在全部变化进程中，我们踩过了很多坑，碰到过很多严重技术应战。

诞生期—技术架构选型V1.0

创业早期，我们的初始创业团队在停止架构选型时，首要基于以下几点停止斟酌：

在创业早期，研发资本有限，研发人力有限，技术储备有限，需要挑选一个易保护、简单的技术架构；产物需要快速研发上线，并可以满足快速迭代要求，现真相况决议了一路头没偶然候和精神来挑选一个过于复杂的散布式架构系统，研发速度必必要快；创业早期，营业复杂度比力低，营业量也比力小，假如挑选过于复杂的架构，反而会增加研举事度以及运维难度；顺从挑选合适的技术而不是最好的技术原则，并权衡研发效力和产物方针，同时创业早期贝聊只要一个PHP研发职员，过于复杂的技术架构必定会带来比力高昂的进修本钱。

正是基于以上几点斟酌，终极挑选了典范的LNMP技术架构，贝聊V1.0架构就这样诞生了，为了加速产物研发速度，尽快上线产物，首期经过外包公司实现了研发以及摆设，后续由我们的PHP研发职员接手，并停止后续的迭代开辟。












早期摆设时，摆设了三台ECS办事器，其中接入层nginx与系统摆设在同一台机械，RDS数据库一台机械，Memcached缓存一台机械，V1.0架构具有以下特点：

单体架构，架构简单，清楚的分层结构；可以快速研发，满足产物快速迭代要求；没有复杂的技术，技术进修本钱低，同时运维本钱低，无需专业的运维，节省开支。

LNMP架构支持贝聊营业成长了快要一年半左右的时候，简单、易保护的架构为贝聊的快速成长做出了很大的进献，时代营业成长敏捷，用户体量也越来越大，原有架构逐步表暴露越来越多的题目。

长大期—技术架构重构V2.0

我是在2015年头加入了贝聊，初始研发团队只要三人，有幸在这一期间

主导了贝聊技术架构重构，并履历了贝聊后续的几次架构演进旅程，将原有PHP单体架构重构为JAVA散布式架构。

首先谈一谈我们做技术架构重构的契机，重构并驳诘在怎样做，而是难在何时起头做，所以我们做架构重构的契机首要基于以下几点：

原有LNMP架构履历了两个团队研发和保护，外包团队和公司PHP研发职员，由于营业变化比力快，原本的数据库设想逐步表暴露来很多题目，很多表设想不公道， 很多字段界说不清，比力紊乱；2015年，由于营业成长，贝聊app需要拆分为两个客户端：贝聊家长端和贝聊教员端，经过度歧的客户端来办事分歧的用户群体，到达精准运营的目标，假如在原有架构上继续停止开辟，则会致使新旧接口逻辑混在一路，而且早期的很多接口界说不是很标准，保护起来越来越麻烦、越来越费劲；原有API接口系统是单体架构，里面包括了各类接口，夹杂了各组营业逻辑处置，一切功用都集合在API接口系统中，代码很是臃肿，营业很是复杂，迭代开辟的速度也逐步减慢，各类性能题目经常爆出，BUG也比力多，而且摆设困难，任何点窜每次都需整体摆设。由于营业逻辑混杂在一路，新入职研发职员需要很长时候才可以完全熟悉系统，很难快速经过以点及面的方式切入系统；所稀有据存储在一个RDS数据库中，只利用了一个主库，没有从库，同时很多系总共用一个数据库，一方面数据库没有做到物理上的隔离，另一方面很多表都放在了同一个数据库中，经常会碰到一个慢查询大概其他性能题目，致使全部RDS各项目标飙升，形成雪崩效应，一切系吐洮锁出现故障，终极都不能拜候；公共办事耦合比力严重，很多第三方办事都散落在各个系统里面，未便于同一保护，当需要点窜公共办事参数大概做其他调剂时，需要深入到每个系统里停止点窜大概排查，很是麻烦，还很是轻易出现遗漏，终极发生BUG，急需自力拆分出公共办事，将公共办事从营业系统中解耦出来，由专人停止自力保护、自力摆设；我们新的研发团队都具有丰富的JAVA散布式架构设想经历，具有高并发、高可用经历，是以将原本的单体架构重构为JAVA散布式架垢荷饲顺势而为。

由于公司营业高速成长，假如停下来专门做技术架构重构是不成能的，我们挑选了在保护现有系统的根本上，同时停止新的技术架构重构工作。重构时代，在原有PHP研发团队的大力支援下，我们的重构工作还算很是顺遂，既保障了营业的快速迭代需求，又成功完成了新的技术架构重构，新的V2.0架构以下：












在V2.0架构期间，初步实现了散布式摆设架构，按照分歧的功用以及营业逻辑，完成系统级此外拆分，同时对第三方办事停止解耦，拆分出了自力的办事模块，针对DB，我们实现了系统级拆分以及物理自力摆设，并实现了数据库主从分手，同时引入了MQ消息行列，并利用SLB实现了负载平衡和带宽流量进口同一。

V2.0期间的架构具有以下特点：

散布式摆设架构，系统易扩大；系统级拆分，拆分出营业功用逻辑自力的子系统，并自力拆分出DB；初步实现了办事化，系统间挪用利用Hessian实现RPC；DB实现了物理隔离，避免之前单DB出故障，激发营业连锁故障，同时实现了数据库主从分手；引入MQ消息行列实现消息和使命异步化，加速接口响应速度，提升用户体验，同时针对一些消息推送使命也实现异步化，避免早期的轮询MySQL机制，削减消息推送延时，提升消息推送速度；利用SLB实现了Nginx负载平衡，在V1.0架构期间，我们的Nginx是单点摆设，若一台Nginx办事器挂掉，则会影响很多营业系统，有单点故障风险，经过SLB实现多台Nginx负载平衡，到达高可用的目标，避免单点故障。

系统拆分和DB拆分

针对系统拆分以及DB拆分，我们经过两个阶段来完成该项工作。

第一阶段

首先在系统层面停止拆分，将原本的大系统拆分出多个营业逻辑自力的子系统，而DB临时不停止拆分，多套系统还继续共用一个DB，只是按照营业逻辑分别各个系统所依靠的表，分歧营业逻辑系统之间不能相互拜候表，这样新系统只拜候自己所归属的表，经过此种计划，可以保证原有系统营业不受影响，同时新拆分的营业系统研发工作也可以顺遂停止，此阶段大要花费了我们几个月的时候，终极顺遂完成系统层面的拆分。

第二阶段

在完成系统层面拆分以后，我们紧接实在施DB层面的拆分，将各个子系统所依靠的表自力拆分出来，别离放置到分歧的RDS数据库，实现物理的隔离，同时实现了数据库主从分手。终极实现结果以下图：












初步办事化

本阶段，我们采用了比力简单易用的Hessian实现早期的RPC办事化。针对第三方公共办事，从原有系统中解耦出来，自力拆分出办事化组件，并做自力摆设，供其他营业系统同一挪用。而系统间挪用也经过Hessian来实现RPC远程挪用。

SLB负载平衡

在V1.0架构时代，我们的Nginx都是单点摆设，一旦一台Nginx办事器出现故障，则会涉及到大量营业系统，风险很是大，以下图：












在V2.0架构时代，我们引入了SLB实现负载平衡，SLB设置了多台Nginx，同时在营业系统层面也实现了负载平衡，避免了单点故障，到达高可用的目标。












爆发期—微办事架构V3.0

进入2016年以来，贝聊营业高速成长，用户范围在短时候内增加数百万，同时各个营业线逐步铺开，营业场景加倍复杂，代码范围收缩得也很是快，研发团队敏捷到达了几十人范围，一个系统多人开辟，研发职员条理纷歧，标准难以同一，同时营业逻辑耦合严重，每次上线都需要将全部大系统整体打包上线，风险很是大，而且新人入职以后进修本钱很是高。是以我们引入了微办事架构，将营业逻辑拆分为自力的微办事组件，每个微办事都围绕着具体营业停止构建，由专人研发和保护，并由专人做性能优化和架构优化，各个微办事组件的研发与上线互不影响。

连系V2.0架构，在实施微办事架构时，基于多方面斟酌，我们挑选了Dubbo作为散布式微办事框架。

成熟的高性能散布式框架，今朝很多公司都在利用，已经承受住各方面性能考验，比力稳定；可以和Spring框架无缝集成，我们的架构正是基于Spring搭建，而且接入Dubbo时可以做到代码无侵入，接入也很是方便；具有办事注册、发现、路由、负载平衡、办事升级、权重调理等才能；代码开源，可以按照需求停止本性化定制，扩大功用，停止自研发；

在做微办事时，我们斟酌了以下几个关键点：

以办事为中心，一切都是办事，每个办事都针对单一营业停止封装，保证功用完整性和职责单一性；松耦合性，办事之间功用自力，可以自力摆设，办事之间相互依靠；高扩大性，分离资本，团队协同工作，可无穷扩大，更高的代码重用率。

在实施微办事架构时，首要斟酌从以下几个方面停止实施：

自力功用逻辑拆分为微办事，自力摆设，自力保护；系统功用全数经过挪用微办究竟现，系统不能间接拜候DB；小数据量高并发挪用利用Dubbo长毗连协议停止通讯，大数据量办事比如文件、图片、视频等利用Hessian协议停止通讯；每个微办事都保护自力的DB。

微办事拆分案例

1. 班级静态微办事

贝聊的班级静态是一个高频次利勤奋用，园长、教员、家长都可以在班级停止公布静态，经过点赞、答复停止互动。随着贝聊营业飞速成长，用户范围爆发，天天都发生数十万的班级静态量，同光阴答复量和点赞量均到达了数百万级别。面临如此大范围的数据量，我们一方面要应对高并发的性能压力，另一方面又要应对数据压力，原本的班级静态功用散落在API接口系统以及背景治理系统中，相关的表也与原有系统同享一个DB，迫切需要我们拆分出自力的班级静态微办事组件，同时还需要做分库分表削减单数据库压力。是以我们专门抽调精壮研发人力，拆分出了班级静态微办事组件。

旧班级静态挪用方式以下












班级静态微办事组件挪用方式以下：












拆分出班级静态微办事以后，我们处理了以下题目：

班级静态微办事对营业挪用方通明，营业挪用方只需挪用接口即可，无需关注技术实现细节；代码复用性，班级静态营业逻辑零丁抽出来做成自力微办事组件，营业系统不再散落班级静态营业逻辑代码、无需再停止代码拷贝；采用DRDS实施了分库分表，处理了单数据库数据量大、数据处置才能有限的瓶颈题目，在单数据库情况下，由于数据量比力大，高并发期间，经常碰到性能题目，接口响应速度很是慢，在实施分库分表以后，班级静态接口的整体性能提升了几倍，用户体验很是好，高并发期间也没有了性能题目。

2. 用户通行证微办事

很多创业公司，在一路头成长时，为了追求速度，同时由于人力不敷，都是将用户数据表与营业数据表临时放在了一个DB里面，贝聊早期也是这样，这就形成磷器个营业系统都是自己别离写DAO来获得用户数据，发生了大量反复的用户逻辑拷贝代码。随着营业成长的越来越快，越来越多的营业系统都需要拜候用户数据，用户逻辑代码散落在各个营业系统，用户数据越来越难保护，复杂度越来越高，同时用户量越来越大，经常会碰到高并发性能题目，不轻易做自力性能优化，是以拆分出自力的用户通行证微办事迫在眉睫。

旧用户数据获得方式












用户通行证微办事












拆分出用户通行证微办事以后，我们处理了以下题目：

代码复用性，本来几近每个营业系统都散落有用户逻辑代码，处处都是拷贝代码，拆分出用户通行证微办事以后，营业系统只需挪用用户通行证微办事接口即可；用户数据分歧性，之前由于获得以及点窜用户数据代码散落在各个营业系统，经常会发生一些用户脏数据，而且很难查询在哪个系统点窜了用户数据，同时由于分歧的研发职员开辟保护分歧的营业系统，也给保护用户数据分歧性带来了很大的应战，拆分出用户通行证微办事以后，一切跟用户逻辑相关的功用，都由用户通行证微办事供给，保证了点窜数据以及获得数据的接口分歧性；用户数据解耦，原有营业系统中经常会join用户表获得用户数据，难以拆分，拆分出微办事以后，用户数据库自力设想摆设，方便停止扩容以及性能优化。

微办事治理

微办事架构开辟、测试、摆设复杂度远远大于单体架构，是以需要构建可以支持微办事架构的托付和运维才能。

1. 版本公布系统

微办事架构的利用开辟、摆设的复杂度都是远大于单体架构利用的，大量的微办事组件假如仍然靠运维职员手工的设置治理明显是难于对付了，是以我们研发了自动化摆设和公布的版本公布系统，我们的版本公布系统具有以下特征：

项目设置包括项目称号、治理员、项目成员、SVN/Git地址、帐号、办事启动的Shell、自界说剧本、分歧情况的JVM设置、Web容器设置等等；依照项目设置好以后，可以倡议上线申请单，经过审批以后，一键即可摆设；支持灰度公布，可以灰度挑选办事器停止版本公布，确保版本公布平平稳定；可以实时收集摆设进程发生的日志，可视化实时监控摆设进程发生的题目；针对公布异常，我们有公布异常处置机制，针对有多台办事器的情况，可以挑选只要有失利就停止公布，即一台公布出错，后续其他办事器停止公布，也可以挑选非论能否有失利都继续公布；快速回滚，针对版本公布出现异常的情况，我们支持快速回滚，可以快速回滚到上一个稳定的版本。

经过版本公布系统，实现代码版本治理、一键摆设上线、一键快速回滚、上线单申请、上线考核以及上线日志等。

2. 开辟测试公布摆设

针对微办事复杂的架构，为了保证每个微办事托付的质量，我们摆设了四个情况：

开辟情况，供研发职员在开辟、调试阶段利用；测试情况，研发职员在开辟情况完成一切功用开辟、测试以后，摆设给测试职员停止验收的情况；预公布情况，在完成测试情况的功用验收以后，功用公布至生产情况前的一个预演情况，与生产情况共用不异的数据库、缓存、MQ消息行列等，用来在微办事上线生产情况前，确认能否还存在BUG等题目，不会影响生产情况的用户，终极用来确保上线生产情况成功；生产情况，即线上情况，是面向用户的线上情况。

经过以上四个情况，确保微办事组件的研发、测试、公布的质量。

3. 散布式设置中心以及散布式使命调剂平台

随着微办事架构的实施，我们拆分出了很多的微办事以及子系统，各类设置信息都以明文形式设置在设置文件中，同时各类按时使命也散落在各个微办事以及子系统中，很是难治理。是以我们挑选了合适的散布式设置中心以及散布式使命调剂平台

Disconf散布式设置治理平台，实现了设置公布同一化，一切设置都存储在云端系统，用户同一在平台上停止公布、更新设置，变动设置时，无需重新打包或重启微办事，经过治理平台间接点窜即可，同时我们停止了本性化定制研发，一切设置信息都实现了加密方式，避免账号、密码等敏感信息泄露；

Elastic-Job散布式使命调剂平台，实现了按时使命注册中心、使命分片、使命运转办事器弹性扩容缩容、生效转移、使命停止规复和禁用等特征，更方便的治理散布式架构情况中的按时使命。

4. 全链路跟踪

微办事架构拆分了大量的子系统以及微办事组件，面临如此复杂大范围散布式集群，一次链路挪用能够会发生在多个微办事组件之间，若何停止链路挪用追踪，若何快速发现一次接口挪用进程中哪些地方需要优化、哪个微办事接口致使了整体挪用比力慢。针对上述题目，我们引入了美团点评的APM工具Cat实时监控系统，与Dubbo办事化框架停止整合，经过全局链路ID，实现链路追踪功用。

5. 微办事授权

默许Dubbo没有实现办事授权功用，系统挪用微办事、微办事之间挪用均没有实现授权考证，都是间接拜候微办事组件接口，是以我们针对Dubbo停止了本性化定制研发，研发了微办事授权认证中心，经过授权认证保证焦点微办事接口的挪用平安性。

6. 微办事监控

拆分出大量的微办事组件，我们面临的是若何监控这么多的微办事运转状态，我们采用了Dubbo自带的简易监控中心，监控微办事组件的成功率、失利率、均匀耗时、最大耗时、并发量等目标，经过这些目标发现微办事性能瓶颈，进而优化微办事性能。同时我们停止本性化定制扩大与研发，针对Dubbo接口挪用，统计接口耗时排行、接口失利排行、接口拜候异动排行等等，经过定制化研发的统计报表，更直观的监控Dubbo接口性能。

7. 微办事治理

我们利用Dubbo的治理控制台，实现对微办事的路由法则设置、拜候控制、权重调理、办事升级、办事禁用、容错等功用，可以很是方便的治理运转中的微办事组件。

经过一年多的微办事化过程，V3.0架构以下：












V3.0微办事架构具有以下特点：

完全实现了散布式摆设架构，系统与微办事组件都很是轻易扩大；以办事为中心，周全构建了微办事组件；系统、微办事组件、缓存、MQ消息行列、DB等均无单点风险，全数实现了HA高可用；

未来—贝聊架构演进V4.0

V3.0架构虽然实现了微办事架构，但该架构还存在以下可以继续演进的点：

Docker容器摆设，Docker具有轻量级、快速摆设、隔离利用、跨平台的上风，微办事很是合适与Docker连系停止快速摆设，今朝虽然我们实现了微办事架构，但还未做到快速弹性扩大，假如将微办事与Docker容器停止连系，可以实现快速弹性扩大，营业高峰期可以快速自动扩大办事器，营业低峰期可以自动接管办事器，接下来我们行将实施微办事组件的Docker容器化摆设；同一API网关，今朝我们的焦点API还只是一个同一的代理层，尚不具有网关的身份认证、防报文重放与防数据篡改、营业鉴权、流量与并发控制等等功用，实施API网关后，可以实现前后端分手，供给便利的监控、报警、分析，还可以供给严酷的权限治理以及流量限制，保障API的平平稳定。接下来我们将实施同一的API网关控制；跨IDC机房摆设，今朝我们的系统还是单机房摆设，单机房不具有冗余以及容灾机制，首先我们将逐步实施同地多机房摆设，先具有多机房摆设才能，避免单机房故障，最初我们再实施异地跨IDC机房摆设，到达异地冗余高可用以及用户就近拜候的目标。

总结

架构演进一向在路上，架构要围绕营业停止，不能离开于营业，分歧的营业期间需要分歧的架构。

单体利用架构，更合适创业早期，公司需要快速试错以及考证市场反应，需要更快的研发速度，同时研发职员比力少，而单体利用架构比力简单，可以快速切入，对研发职员的技术栈要求不是出格高，可以快速上手快速研发，但在设想单体利用架构时最好可以提早计划好未来的扩大性，可以在营业层面先计划好，便于往后营业成长到一定例模，可以快速停止解耦，实施微办事化架构。

当企业成长到一定例模，营业线变的越来越多、越来越复杂，同时研发职员的数目也快速增加，单体利用架构就会渐渐表暴露来弊端，大量的研发职员在一个系统上停止开辟，缺少并行研发才能，大量的营业代码耦合在一路，同时研发效力很是低。微办事架构可以更好的停止营业解耦，具有更好的扩大性以及自力性，可以进步研发团队间的并行化研发速度，提升效力、进步模块复用性，具有高可用、高并发特征。但微办事架构对办事治理的才能要求比力高，保护本钱也会比单体利用高，需要强大的办事治理支持，对研发职员的技术才能要求也比力更高。

今朝我们仍然在架构演进的路上，履历了以上几次架构过程，虽然获得了一定的进步，但仍然有很多应战期待我们去迎战。计划技术架构需要综合斟酌营业的范围、营业的时效性、研发团队的范围、研发的技术才能、根本情况设置等。架构来历于营业，架构演进的生命周期只要完善婚配好营业的生命周期，才能终极发挥出最好的结果。

来历:21CTO