63 lines
7.5 KiB
Markdown
63 lines
7.5 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
099 徐裕键：业务高速增长过程中的技术演进
|
||
你好，我是贝贝网合伙人兼研发副总裁徐裕键。上一期文章中，我跟你分享了业务高速增长带来的业务和团队两方面的挑战，以及如何通过规范流程制度、搭建人才梯队、完善组织架构等方法来应对这些挑战。
|
||
|
||
然而，在业务高速增长的过程中，来自技术的挑战也不可忽视。贝贝网从一个电商新秀到行业独角兽，只用了短短两三年的时间，看似顺利，但其中的酸甜苦辣只有我们自己知道。所以今天就想扒扒皮，和你分享一下我们业务扩张过程中在技术上踩过的那些坑，以及我们是如何应对的。
|
||
|
||
业务规模和复杂度快速增长带来的挑战
|
||
|
||
其实，创业最初，我们曾怀疑过贝贝网这个平台的可能性，因为在早期的电商淡季时期，我们连三个九的业绩都达不到。后来，在双十一流量压力的作用下，我们把业绩做到了四个九以上，才打消了我们的疑虑。
|
||
|
||
另外，最开始我们是移动电商，APP版本的迭代速度非常慢，早期可能一个月更新一个版本都非常困难。后来，经过技术的不断演进、团队的不断迭代，我们能够做到每周更新一个版本，而且新版本的缺陷率从原先的50%降低到5%以上。50%意味着，在早期，我们上线的100个需求里面，有50个需求是有缺陷的，需要返工的。
|
||
|
||
版本更新速度的提升与相应错误率的下降，这背后起支撑的是一个团队的持续迭代。一个人可以走得很快，但唯有一个团队，才能走得更远。
|
||
|
||
再来看来自于技术的挑战。公司在快速发展过程中，相应的业务量也是快速增长的，最初可能只有一个单一的产品、一个简单的业务，到后面，随着业务、产品的成熟，逐渐将它铺开后，可能会出现多个产品，甚至数十条业务线，都需要并行迭代的情况。此时便会衍生出更多的问题，具体可以分为三点：
|
||
|
||
第一个问题是，原先我们习惯于在一个工程或一个系统应用上进行开发，长期以往，代码会越堆越多，导致这个系统越来越腐化，架构越来越不稳定，出现越来越多的耦合。
|
||
|
||
这时就会发现，团队的新成员进来后不敢写代码，团队中的老人也不敢对这个存在复杂耦合性的系统轻举妄动。因为，极有可能你动了某个地方，就会导致整个系统出现更大的问题。一旦这种可能性发生，那之前的什么代码冲突，相较而言就是非常小意思的事情了。
|
||
|
||
第二个问题是，当大家都在一个工程、一个应用上进行开发，并且有多条业务线并行迭代的时候，你会发现，每个团队直接的步伐并不一致，互相之间可能会有诸多争论。这样就会导致版本更新的效率大大降低，也加大了需求上线的难度，比如大家可能需要花费半天的时间才能够完成上线验证，效率极其低下。
|
||
|
||
第三个问题是，由于系统太过耦合，可能某个新功能上线后对于全站业绩增长的影响非常有限，但因为系统扛不住新功能带来的流量，结果导致核心链路交易服务都不可用了。
|
||
|
||
业务系统解耦合及平台化推进
|
||
|
||
说了这么多问题，我们当时是如何应对这些技术难题的呢？
|
||
|
||
首先，我们要明确一个观点：保证生存是首要目的，永远没有非常完美的产品方案，我们必须要不停地进行开发和迭代。所以，我们必须具备一种快速试错、低成本试错的能力，使产品和业务完成快速迭代。并且，当这个模式成熟后，能够帮助产品和业务快速进行规模化，再通过这种规模化的能力，实现公司商业价值最大化。
|
||
|
||
回到具体的技术挑战，公司规模上来后，我们在每个技术领域都有非常大的技术演进，是基于全栈的技术演进，从APP端组件化动态化，到业务层组件化，到服务化，一直到底层数据库拆分、运维自动化、持续集成能力的提升等，我们都做了很多布局，而且很多都被证明是非常有效的。同时，整个系统的基础架构设施也在不断完善和配套。最有力的表现就是，后台研发同学的交付能力，直接是翻倍的提升。
|
||
|
||
其实，归纳起来就是通过服务框架对应用进行拆分解耦、采用异步消息来对系统进行解耦、使用分布式数据访问实现数据层的无限扩容。
|
||
|
||
在APM应用性能管理方面，我们自研了一套从客户端到后端的全链路应用市场监控，便于我们对性能进行优化。其监控管理对象也从最初的单应用演进为多应用。
|
||
|
||
在应用拆分、服务化之后，我们还自研了一套私有云系统，改进了系统的部署方式，从原来的集中式部署，到分布式部署，再演进到单元化部署。这样一来，原本交付一个资源至少需要一天以上，现在只需要几分钟就能进行扩容，效果立竿见影。
|
||
|
||
在监控告警方面，我们从原来的单机房部署，一路演进到异地多机房部署，基于这样的监控告警体系，当我们的业务指标发生变化时，能够做到一分钟之内告警，特别是核心业务指标发生变化时，我们可以及时进行处理。
|
||
|
||
在持续集成方面，我们也从最初的单系统优化做到后面的结构型优化，能够提供非常灵活的灰度发布机制、非常快捷的回滚机制，确保即使出现问题，它的影响也能控制到最小。
|
||
|
||
在大数据方面，我们很早就开始布局，并组建大数据团队，目前已经演进到机器学习阶段。比方说在客服上，机器客服能够帮助节省一半的客服人员，减少人力资源消耗。另外，对运营也有非常大的帮助，比如通过自动化排期，基本能做到减少1/3运营人员的投入。
|
||
|
||
当然，在技术之外，流程是保证保证快速迭代的关键，对此，我们定了两点原则：一是每个阶段都实行准入制度，明确需求；二是每个环节都检查输出，包括质量和时间两个维度。在具体执行中，我们推行短项目迭代制，正如之前提到的，没有完美的产品方案，我们要先求有，再求优，小步快跑、快速迭代，而所有的技术与系统都要能支撑我们能够迅速验证产品。
|
||
|
||
总结一下，技术上的挑战，来自于业务高速增长形成规模化之后，带来的系统复杂度的上涨，而解决的重点在于，通过服务框架对应用进行拆分解耦、采用异步消息来对系统进行解耦、使用分布式数据访问实现数据层的无限扩容。
|
||
|
||
然而需要注意的是，对创业团队来说，如果想要把握住机会，就必须做到快，因此，在技术演进的时候，也要学会克制自己的技术洁癖，不要追求完美，适合的才是最好的。
|
||
|
||
作者简介
|
||
|
||
徐裕键，贝贝网合伙人兼研发副总裁。负责贝贝技术团队管理，从0到1搭建贝贝移动电商产品和技术架构，推动集团各个技术领域快速演进，完善技术团队的梯队搭建和文化建设。
|
||
|
||
（本文整理自徐裕键在ArchSummit全球架构师峰会上的分享，有删减。）
|
||
|
||
|
||
|
||
|