目录:
1、综合
2、基础层设计
3、应用层设计
4、总结
我在2年之前,写过一篇中小型项目的前端架构浅谈。随着能力的上升,以及在阿里巴巴工作的经验,是时候写一篇大型项目的前端架构分析了。
本篇文章不会更多侧重于具体技术实现,而是尝试从更高角度出发,分析为什么要这么做,这些设计能解决什么问题,成本和收益如何。
由于作者能力有限,可能会有所缺漏或者部分错误,欢迎读者指出。
本篇文章,适用于单个/多个大型项目、拥有超过10个以上的前端开发的场景。
前端项目的规模不同,成本收益比也会有所差别。通常来说,人员越多、项目复杂度越高,那么收益/成本的比值越大。
对于人数较少、项目简单的开发团队,可能有部分措施不适用,因此应该根据具体情况来选用。
【1】解决问题:前端架构的设计,应是用于解决已存在或者未来可能发生的技术问题,增加项目的可管理性、稳定性、可扩展性。
【2】人效比:对于需要额外开发工作量的事务(本文中存在一些需要一定开发量的内容),我们在决定是否去做的时候,应该考虑到两个要素:第一个是花费的人力成本,第二个是未来可能节约的时间和金钱、避免的项目风险与资损、提高对业务的支撑能力以带来在业务上可衡量的更高的价值、以及其他价值。
【3】定性和定量:架构里设计的内容,一定要有是可衡量的意义的,最好是可以定量的——即可以衡量带来的收益或减少的成本,至少是可以定性的——即虽然无法用数字阐述收益,但我们可以明确这个是有意义的,例如增加安全性降低风险。
【4】数据敏感:专门写这一条强调数据作为依据的重要性。当我们需要说服其他部门/上级管理者,以推动我们设计的内容时,只有数据——特别是跟钱有关的数据,才是最有说服力的证明。
由于篇幅所限,本文很难直接给出定量的值,因此建议架构设计者,先确保项目中设计使用2.7里的埋点系统,根据埋点系统获取的数据,对项目效果进行定量分析,并以此写成PPT和其他部门/上级管理者进行协调。
分为基础层和应用层。
基础层偏基础设施建设,与业务相关性较低。
应用层更贴近用户,用于解决某一个问题。
部分两个都沾边的,根据经验划分到其中一个。
由于已经谈到架构层级,因此很多内容,并不仅仅只属于前端领域,有很多内容是复合领域(前端、后端、运维、测试),因此需要负责架构的人,技术栈足够全面,对未来发展有足够的前瞻性。
文章的内容结构为:【项目】—>【解决的问题和带来的好处】—>【项目的实际意义】
这个是基础的基础了。本不应该提的,不过考虑到我最近面试的几家公司,有的公司(人数并不少)并没有使用Gitlab,因此专门提一下,并且使用这个的难度非常低。
强烈建议使用Gitlab进行版本管理,自建Gitlab难度并不大,方便管理,包括代码管理、权限管理、提交日志查询,以及联动一些第三方插件。
意义:公司代码是公司的重要资产,使用自建Gitlab可以有效保护公司资产。
版本管理的几个关键点:
意义:提高项目的可控性。
这个工具用于在代码发布后,执行一系列流程,例如自动编译打包合并,然后再从Gitlab发布到CDN或者静态资源服务器。
使用这个工具,可以让一般研发人员不关心代码传到Gitlab后会发生什么事情,只需要专心于开发就可以了。
意义:让研发人员专心于研发,和环境、运维等事情脱钩。
纯前端版本发布分为两步:
解决的问题是:当前端需要发布新版本时,可以不依赖于后端(根据实际情况,也可以不依赖于运维)。毕竟有很多需求并不需要后端介入,单纯改个前端版本后就要后端发布一次,显然是一件非常麻烦的事情。
这个需要专门的工具,用于配置版本发布,我最近就在写这个。
意义:提高发布效率,降低发布带来的人员时间损耗(这些都是钱),也可以在前端版本回滚的时候,速度更快。
适用场景:有比较多独立中小项目。好处:
意义:提高开发人员在多个项目之间的快速切换能力,提高项目可维护性,统一公司技术栈,避免因为环境不同导致奇怪的问题。
适用场景:需要seo且前端使用react、vue,或前端介入后端逻辑,直接读取后端服务或者数据库的情况。
意义:让前端可以侵入后端领域,质的提升对业务的支持能力。
强烈推荐前端做自己的埋点系统。这个不同于后端的日志系统。
前端埋点系统的好处:
埋点系统是前端高度介入业务,把握业务发展情况的一把利剑,通过这个系统,我们可以比后端更深刻的把握用户的习惯,以及给产品经理、运营等人员提供准确的数据依据。当有了数据后,前端人员就可以针对性的优化功能、布局、页面交互逻辑、用户使用流程。
埋点系统应和业务解耦,开发人员使用时注册,然后在项目中引入。然后在埋点系统里查看相关数据(例如以小时、日、周、月、年为周期查看)[原创水印-作者:零零水(王冬),微信:qq20004604]。
意义:数据是money,数据是公司的生命线,数据是最好的武器。
监控和报警系统应基于埋点系统而建立,在如以下场景时[原创水印-作者:零零水(王冬),微信:qq20004604]触发:
建设这个系统的好处在于,提前发现一些不容易发现的bug(需要埋点做的比较扎实)。有一些线上bug,因为用户环境特殊,导致无法被开发人员和测试人员发现。但其中一部分bug又因为不涉及资金,并不会导致资损(因此也不会被后端的监控系统所发现),这样的bug非常容易影响项目里某个链路的正常使用。
意义:提高项目的稳定性,提高对业务的把控能力。降低bug数,降低资损的可能性,提前发现某些功能的bug(在工单到来之前)。
前端的安全管理,通常要依赖于后端,至于只跟单纯有关系的例如dom.innerHTML= 'xxx '这种太基础,就不提了。
安全管理的很难从架构设计上完全避免,但还是有一定解决方案的,常见安全问题如下:
意义:减少安全漏洞,避免用户受到损失,避免遭遇恶意攻击,增加系统的稳定性和安全性。
Eslint的好处很多,强烈推荐使用:
总的来说,eslint推荐直接配置到脚手架之中,对我们提高代码的可维护性的帮助会很大。可以考虑在上传到gitlab时,硬性要求eslint校验,通过的才允许上传。
意义:提高代码的可维护性,降低团队协作的成本。
灰度发布是大型项目在发布时的常见方法,指在发布版本时,初始情况下,只允许小比例(比如1~5%比例的用户使用),若出现问题时,可以快速回滚使用老版本,适用于主链路和访问量极大的页面。
好处有以下几点:
灰度发布通常分为多个阶段:【1】1%;【2】5~10%;【3】30~50%;【4】全量推送(100%)。灰度发布一定要允许配置某些IP/账号访问时,可以直接访问到灰度版本。
意义:降低风险,提高发布灵活度。
这个并不是指常见的前后端分离,而是指在分配前后端管控的领域。
中小项目常见的情况是后端只提供接口和让某个url指向某个html,前端负责html、css、js等静态资源。
但大型项目并不建议这么做,建议前端负责除html以外的静态资源,而html交给后端处理,理由有很多:
意义:更规范的进行页面管理,降低页面和功能的耦合度,减少复杂页面的环境配置时间。
Mock也是常见前端系统之一,用于解决在后端接口未好时,生成返回的数据。
我个人不太建议开发一个专门的系统来Mock,更好的Mock手法是直接嵌入到脚手架之中。思路如下:
这种处理,可以降低mock的复杂度,随时更改mock时返回的数据,比单独开发一个mock系统性价比更高。
意义:在前后端并行开发时,降低沟通交流成本,方便开发完毕后直接对接。
备份是常被忽略的一件事情,但当我们遇见毁灭性场景时,缺少备份带来的损失是非常大的,常见场景:
总的来说,没人想遇见这样的场景,但我们必须考虑这种极端情况的发生,因此需要从架构层面解决这个问题。常见方法是定期备份、多机备份、容灾系统建设等。
意义:避免在遭遇极端场景时,给公司带来不可估量的损失。
除了特殊场景,通常推荐使用多页架构。理由如下:
之前面试的一家,采用了单页的形式,之前因为种种原因,同时采用了ng和react。由于项目历史也比较久(3年以上),结果导致目前继续维护更新的难度很大,即使想部分重构,也很麻烦。
意义:降低长期项目迭代维护的难度
在项目比较大的时候,将所有页面的前端文件放入到同一个代码仓库里,我之前参与过一家企业的前端项目开发,发现其就是这么做的。根据使用经验来看[原创水印-作者:零零水(王冬),微信:qq20004604],存在很多问题:
因此,我们应该避免这种现象的发生,个人推荐以应用为单位进行开发、发布。所谓应用即指一个业务涉及到的前后端代码,好处很多:
意义:规范项目,增加代码的安全性,降低项目维护成本。
这个蛮基础的,对于组件库的建设,不建议研发人员较少时去做这件事情,专职前端开发人数少于10人时,建议使用比较靠谱的第三方UI库,例如Antd,这样性价比更高。
设计基础组件库的前提,是要求统一技术栈,这样才能最大化基础组件库的效益。组件库建议以使用以下参考标准:
总的来说,建设起来后,利大于弊,但是需要专人维护,因此还是有一定成本的。
意义:统一不同/相同产品线之间的风格,给用户更好的体验,减少单次开发中写UI组件时浪费的时间和人力,提高开发效率。
前端有三大主流框架,还有兼容性最强jquery,以及各种第三方库,UI框架。因此项目需求如果复杂一些,很容易形成一个大杂烩。因此前端的技术栈必须统一,具体来说,建议实现以下举措:
总的来说,技术栈统一的好处很多,可以有效提高开发效率,降低重复造轮子产生的成本。
意义:
方便招人,简化团队成员培养成本,以及提高项目的可持续性。
常见的问题是IE6、7、8,以及部分小众浏览器(PC和手机)产生的奇怪问题。因此应该考虑统一解决方案,避免bug的重复产生。常见解决方案有:
意义:避免浏览器环境产生的bug,以及排查此类bug所浪费的大量时间。
为了提高公司内部的沟通效率,总结经验,以及保密原因。应建设一个内部论坛+博客站点。其具备的好处如下:
众所周知,大型互联网公司通常都有这样一个内部论坛和博客站点。其降低了公司的沟通和交流成本,也增加了公司的技术积累。
意义:博客增强技术积累,论坛增强公司内部沟通能力。
当公司内部人员较多时,应有一个专门的平_台,来管理、规范用户的权限以及可访问内容[原创水印-作者:零零水(王冬),微信:qq20004604]。权限管理平_台有几个特点:
意义:使得公司内部流程正规化、信息化。
当公司内部业务线比较复杂但相互之间的耦合度比较高时,我们应该考虑设计添加单点登录系统。具体来说,用户在一处登录,即可以在任何页面访问,登出时,也同样在任何页面都失去登录状态。SSO的好处很多:
总的来说,大中型web应用,SSO可以带来很多好处,缺点却很少。
意义:用户体验增强,打通不同业务之间的间隔,降低开发成本和用户管理成本。
前端资源的加载速度是衡量用户体验的重要指标之一。而现实中,因为种种因素,用户在加载页面资源时,会受到很多限制。因此上CDN是非常有意义的,好处如下:
CDN是一种比较成熟的技术,各大云平_台都有提供CDN服务,价格也不贵,因此CDN的性价比很高。
意义:增加用户访问速度,降低网络延迟,带宽优化,减少服务器负载,增强对攻击的抵抗能力。
目前来看,负载均衡通常使用Nginx比较多,以前也有使用Apache。当遇见大型项目的时候,负载均衡和分布式几乎是必须的。负载均衡有以下好处:
负载均衡已经是蛮常见的技术了,好处不用多说,很容易理解。
意义:增强业务的可用性、扩展性、稳定性,可以支持更多用户的访问。
目前常见场景是一个业务,同时有PC页面和H5页面,由于业务是一样的,因此应避免同一个业务有多套接口分别适用于PC和H5端。[原创の水印-作者:零零水(王冬),QQ:20004604]因此解决方案如下:
多端共用接口,是减少开发工作量,并且提高业务可维护性的重要解决方案。
意义:降低开发工作量,增强可维护性。
由于各个公司具体情况不同,项目也具有特殊性,因此以上设计不可强行套入,应根据自己公司规模、项目进展、人员数量等,先添加比较重要的功能和设计。并需要考虑到长期项目的可维护性和发展需要,对部分基础设施进行提前研发设计。
本文转载自:https://juejin.im/post/5cea1f705188250640005472
架构和框架是独立的,本文仅仅是提出一种架构思路,而且这个架构也在百度的某款用户量很大的复杂前端产品中得以应用。基于这一套弹性架构并结合Vue/React的现代化开发理念,可以很好的完成高复杂度的前端系统。
软件架构(software architecture)是一系列相关的抽象模式,用于指导大型软件系统各个方面的设计。传统软件架构描述的对象是直接构成系统的抽象组件,侧重于系统的抽象、拆分、组织方式等
架构师的一个重要职责是,确保团队有共同的技术愿景,以帮助我们向客户交付他们想要的系统。在某些场景下,架构师只需要和一个团队一起工作,这时他们等同于技术引领者。在其他情况下,他们要对整个项目的技术愿景负责,通常需要协调多个团队之间,甚至是整个组织内的工作。
C/S 架构是一种典型的两层架构,其全程是Client/Server,即客户端服务器端架构,其客户端包含一个或多个在用户的电脑上运行的程序,而服务器端有两种,一种是数据库服务器端,客户端通过数据库连接访问服务器端的数据
目的为保证服务器硬件故障时依然可用,数据依然保持并能够访问,手段:数据和服务的冗余备份以及失效转移机制,有状态 :在服务端保留之前的请求信息,用以处理当前请求(例如:session)无状态 :没有特殊状态的服务
动态应用,是相对于网站静态内容而言,是指以c/c++、php、Java、perl、.net等服务器端语言开发的网络应用软件,比如论坛、网络相册、交友、BLOG等常见应用。动态应用系统通常与数据库系统、缓存系统、分布式存储系统等密不可分。
本来没想写这个题材的,为了某某童鞋能够更好的茁壮成长,临时写一篇负载均衡的。负载均衡,大家可能听过什么3层负载均衡、4层负载均衡、7层负载均衡什么的?那这是怎么分的呢,ok,是根据osi七层网络模型来分的,例如nginx是工作在应用层
Kubernetes(k8s)是一款开源的优秀的容器编排调度系统,其本身也是一款分布式应用程序。虽然本系列文章讨论的是互联网架构,但是k8s的一些设计理念非常值得深思和借鉴,本人并非运维专家,本文尝试从自己看到的一些k8s的架构理念结合自己的理解来分析 k8s在稳定性
一般来说,除了当前的系统功能需求外,软件架构还需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。性能是网站的一个重要指标,任何软件架构设计档案都必须考虑可能会带来的性能问题。
本章介绍如何去构建高可用的服务,关键词:服务分级,超时设置,异步调用,服务降级,幂等性设计,一些架构设计中的常用方案,但是需要结合实际业务场景进行设计,没有一套方案能解决所有问题
内容以共享、参考、研究为目的,不存在任何商业目的。其版权属原作者所有,如有侵权或违规,请与小编联系!情况属实本人将予以删除!