创业公司在开始新业务的时期,基本处在试错或原型验证阶段,这个阶段更多是关注业务的本身是否有前景或商业模式,而不会把非常多的精力放在技术的系统架构上,尤其是对于非技术型或不确定型的项目立项阶段。尽管很多技术人员也预料到前期需要很多时间去好好设计系统,才能保证支撑后续可能的业务快速发展,但往往由于时间成本或人力等原因而无法很好地执行。

@[TOC]

一般来讲,创业型的项目对时间的要求非常苛刻,需要在3到6个月时间内完成系统的上线,否则有可能由于业务无法快速上线验证,导致无法获取相关的原始数据进行下
个目标验证,更严重的有可能造成资金链的断裂。罗马不是一天建成的,因此这个阶段会使用相对简单的架构方式来进行设计,本节先从最主要的几点进行说明.

单体架构

对于创业型公司来说,由于人才、技术、资金等重要因素的影响,同时,技术人员为了配合产品的需求,会采用最简单的架构来完成最原始阶段开发,根据我们接触的不少用户反馈,有些企业考虑成本因素,甚至只使用一台服务器或者容器服务。另外,传统官网、论坛等应用,由于早期的设计采用了单体架构来实现,只需要一台服务器或容器来服务即可。对于其他的应用服务器、数据库、静态文件等资源,也是部署到同一台服务器或容器上来服务。最简单的架构模型如图所示。

1
2
3
graph LR
PHP-->Apache
Apache-->Mysql

对于早期的单体应用,应用服务+数据库服务基本上就组成了最原始的架构模型,技术人更多会考虑技术的选型,包括编程语言、版本管理、数据库的类型等。比如PHP的开发者选择PHP-MySQL, Java的开发者采用Tomcat-MySOL等开发方式。

服务器分离

根据线上运行经验,一般的业务的类型,如果每日的用户访问量在百万级别以内,只要进行简单的Web应用性能参数调优、数据库索引优化等,基本上就能保证服务的稳定运行,当然,随着访问量的不断增加,部署在同一台服务器上的应用及数据库服务,会造成服务器的CPU/内存/磁盘/带宽等系统资源竞争,从而相互影响,显然很容易出现性能瓶颈,如果这台服务器出现了宕机或无法恢复的错误,就有可能导致全站不可访问或者数据丢失等情况,后果非常严重,因此大部分产品会将Web应用服务器和数据库服务器进行物理分离,独立部署,相互热备提供服务,只需要增加很少的成本,就能解决对应性能和数据的可靠性等问题.

初期由于各种条件存在不能很好地进行新项目前景的预见,技术人员如果能在最小成本的情况下保证架构的合理性,还能很好地服务产品功能需求,甚至只要在部署架构上稍做调整,就可以防止出现灾难性的问题,这其中也包括很多技术架构上的考虑。

业务模型

一般而言,现阶段的业务比较简单,产品也比较单一,业务会随时根据其运营数据进行调整,因此,这时需要技术人能够较好地把不同的模块分离出来,对于偏业务相关的功能,需要有较好的心态接收随时变化的不确定性,对于后续可能复用或大量依赖的工程,需要进行较好的设计,否则可能在业务爆发时导致业务开发的进度越来越慢,甚至阻碍业务的发展,造成业务时常中断,即使有人力或时间来对系统进行重新设计,也会令技术人员产生抵触心理,同时也会引入较高的风险,因此,基于云原生应用的设计模式在最基础的阶段对架构也有很大的作用,包括考虑如何使用云的弹性,将不可变优势融合到系统的设计中,合理的业务模型分界也是确保后续能发展的重要步骤之一。


总而言之,在早期项目原型验证或者快速试错阶段,采用单体架构具有很大的技术优势,产品的想法也在项目的初始阶段就能进行比较好的迭代开发,发布和部署也比较灵活。然而,随着业务的增长,如果架构还是一成不变的话,带来的技术风险就越来越高.
比如,代码行数的增加影响技术人员的学习成本、业务的变更速度、业务的可靠性、安全性及工程变大后的发布效率等,每次修改都必须反复测试,否则全站随时可能不可用,导致业务中断或者丢失市场的机会,因此,这部分的技术债务必须在业务快速发展的同时,进行技术架构的改造,使其能保证后期业务的支撑,所以,除了业务的发展判断外,对开发人员的技术能力储备和架构远见判断也将成为考虑的事情之一.

架构演化发展历程:

  1. 初创期架构
  2. 快速成长期架构
  3. 分布式服务架构

参考:

  1. 云原生应用架构实践 (网易云基础服务架构团队 著)