常见的前端集成部署方案都有哪些?各自的优缺点是啥?

Posted 2023-05-16

常见的前端集成部署方案有哪些?各自的优缺点是什么?
本人没用过，所以求讲解

好无语，刚刚百度自己错码，然后采纳了，想死的感觉，我还的重新问，求大神讲解

前端行业经历了这么长时间的发展，技术元素非常丰富，这里列举出一般web团队需要用到的技术元素：

开发规范：包括开发、部署的目录规范，编码规范等。不要小瞧规范的威力，可以极大的提升开发效率，真正优秀的规范不会让使用者感到约束，而是能帮助他们快速定位问题，提升效率。

模块化开发：针对js、css，以功能或业务为单元组织代码。js方面解决独立作用域、依赖管理、api暴露、按需加载与执行、安全合并等问题，css方面解决依赖管理、组件内部样式管理等问题。是提升前端开发效率的重要基础。现在流行的模块化框架有requirejs、seajs等。

组件化开发：在模块化基础上，以页面小部件(component)为单位将页面小部件的js、css、html代码片段放在一起进行开发、维护，组件单元是资源独立的，组件在系统内可复用。比如头部(header)、尾部(footer)、搜索框(searchbar)、导航(menu)、对话框(dialog)等，甚至一些复杂的组件比如编辑器(editor)等。通常业务会针对组件化的js部分进行必要的封装，解决一些常见的组件渲染、交互问题。

组件仓库：有了组件化，我们希望将一些非常通用的组件放到一个公共的地方供团队共享，方便新项目复用，这个时候我们就需要引入一个组件仓库的东西，现在流行的组件库有bower、component等。团队发展到一定规模后，组件库的需求会变得非常强烈。

性能优化：这里的性能优化是指能够通过工程手段保证的性能优化点。由于其内容比较丰富，就不在这里展开了，感兴趣的同学可以阅读我的这两篇文章 [1] [2]。性能优化是前端项目发展到一定阶段必须经历的过程。这部分我想强调的一点是 性能优化一定是一个工程问题和统计问题，不能用工程手段保证的性能优化是不靠谱的，优化时只考虑一个页面的首次加载，不考虑全局在宏观统计上的优化提升也是片面的。

项目部署：部署按照现行业界的分工标准，虽然不是前端的工作范畴，但它对性能优化有直接的影响，包括静态资源缓存、cdn、非覆盖式发布等问题。合理的静态资源资源部署可以为前端性能带来较大的优化空间。

开发流程：完整的开发流程包括本地开发调试、视觉效果走查确认、前后端联调、提测、上线等环节。对开发流程的改善可以大幅降低开发的时间成本，工作这些年见过很多独立的系统（cms系统、静态资源推送系统）将开发流程割裂开，对前端开发的效率有严重的阻碍。

开发工具：这里说的工具不是指IDE，而是工程工具，包括构建与优化工具、开发-调试-部署等流程工具，以及组件库获取、提交等相关工具，甚至运营、文档、配置发布等平台工具。前端开发需要工具支持，这个问题的根本原因来自前端领域语言特性（未来我会单独写一篇文章介绍前端领域语言缺陷问题）。前端开发所使用的语言（js、css、html）以及前端工程资源的加载与定位策略决定了前端工程必须要工具支持。由于这些工具通常都是独立的系统，要想把它们串联起来，才有了yeoman这样的封装。前面提到的7项技术元素都直接或间接的对前端开发工具设计产生一定的影响，因此能否串联其他技术要素，使得前端开发形成一个连贯可持续优化的开发体系，工具的设计至关重要。

参考技术A 您好，前端集成解决方案，英文翻译为 Front-end Integrated Solution，缩写fis，发音[fɪs]
前端集成解决方案并不是一个新词汇，将这个词拆开来看，我们能得到：
前端：指前端领域，即web研发中常用的浏览器客户端相关技术，比如html、js、css等
集成：将一些孤立的事物或元素通过某种方式改变原有的分散状态集中在一起，产生联系，从而构成一个有机整体的过程。解决方案：针对某些已经体现出的，或者可以预期的问题，不足，缺陷，需求等等，所提出的一个解决问题的方案，同时能够确保加以有效的执行。
总结来说，前端集成解决方案就是：
将前端研发领域中各种分散的技术元素集中在一起，并对常见的前端开发问题、不足、缺陷和需求，所提出的一种解决问题的方案。

工具是否能提供接入公司已有流程中的接口，比如命令调用，如果工具需要一些系统环境支持，公司的ci流程中是否能支持等问题。
前端领域语言的特点决定了攒一套集成解决方案有很高的实现成本。因为前端语言缺少包、导入、模块等开发概念，这使得各个技术点的解决方案在设计的时候都是考虑被独立使用的情况下如何工作，因此或多或少的会延伸自己的职责。比如模块化框架要附属构建工具，甚至要求后端服务（比如combo），组件化框架自带模块化框架，构建工具自带部署规范等，这就大大提高了将各个技术要素融合起来的成本。
总之，前述的8项技术要素之间有许多联系，这就为打造一套完整连贯的前端集成解决方案带来了较大的挑战。如何兼顾规范、性能、框架、流程、部署等问题，就不是东拼西凑那么简单的事了。后面我会单独撰文介绍如何实现一套集成解决方案。本回答被提问者和网友采纳

常见的分表方式 都有哪些，各自的优缺点

下面来分析一下：

　　一、时间结构

　　如果业务系统对时效性较高，比如新闻发布系统的文章表，可以把数据库设计成时间结构，按时间分有几种结构：

　　1) 平板式

　　表类似：

　　article_200901

　　article_200902

　　article_200903

　　用年来分还是用月可自定，但用日期的话表就太多了，也没这必要。一般建议是按月分就可以。

　　这种分法，其难处在于，假设我要列20条数据，结果这三张表里都有2条，那么业务上很有可能要求读三次表。如果时间长了，有几十张表，而每张表是0条，那不就是要读完整个系统的表才行么?另外这个结构，要作分页是比较难实现的。

　　主键：在这个系统中，主键是13位带毫秒的时间戳，不要用自动编号，否则难以通过主键定位到表，也可以在查询时带上时间，但比较烦琐。

　　2) 归档式

　　表类似：

　　article_old

　　article_new

　　为了解决平板式的缺点，可以采用时间归档式设计，可以看到这个系统只有两张表。一张是旧文章表，一张是新文章表，新文章表放2个月的信息，每天定期把2个月中的最早一天的文章归入旧表中。这样一方面可以解决性能问题，因为一般新闻发布系统读取的都是新的内容，旧的内容读取少;第二可以委婉地解决功能问题，比如平板式所说的问题，在归档式中最多也只需要读2张表就完成了。

　　归档式的缺点在于旧表容量还是相对比较大，如果业务允许，可对旧表中的超旧内容进行再归档或直接清理掉。

　　二、版块结构

　　如果按照文章的所属版块进行拆表，比如新闻、体育版块拆表，一方面可以使每个表数据量分离，另一方面是各版块之间相互影响可降到最低。假如新闻版块的数据表损坏或需要维护，并不会影响到体育版块的正常工作，从而降低了风险。版块结构同时常用于bbs这样的系统。

　　板块结构也有几种分法：

　　1) 对应式

　　对于版块数量不多，而且较为固定的形式，就直接对应就好。比如新闻版块，可以分出新闻的目录表，新闻的文章表等。

　　news_category

　　news_article

　　sports_category

　　sports_article

　　可看到每一个版块都对应着一组相同的表结构，好处就是一目了然。在功能上，因为版块之间还是有一些隔阂，所以需要联合查询的需求不多，开发上比时间结构的方式要轻松。

　　主键：依旧要考虑的，在这个系统中，主键是版块+时间戳，单纯的时间戳或自动编号也能用，查询时要记得带上版块用于定位表。

　　2) 冷热式

　　对应式的缺点是，如果版块数量很大而且不确定，那要分出的表数量就太多了。举个例子：百度贴吧，如果按一个词条一个表设计，那得有多少张表呢?

　　用这样的方式吧。

　　tieba_汽车

　　tieba_飞机

　　tieba_火箭

　　tieba__unite

　　这个表汽车、火箭表是属于热门表，定义为新建的版块放在unite表里面，待到其超过一万张主贴的时候才开对应表结构。因为在贴吧这种系统中，冷门版块肯定比热门版块多得多，这些冷门版块通常只有几张帖子，为它们开表也太浪费了;同时热门版块数量和访问量等，又比冷门版块多得多，非常有特点。

　　unite表还可以扩展成哈希表，利用词条的md5编码，可以分成n张表，我算了一下，md5前一位可分36张表，两位即是1296张表，足够了。

　　tieba_unite_ab

　　tieba_unite_ac

　　…

　　三、哈希结构

　　哈希结构通常用于博客之类的基于用户的场合，在博客这样的系统里有几个特点，1是用户数量非常多，2是每个用户发的文章数量都较少，3是用户发文章不定期，4是每个用户发得不多，但总量仍非常之大。基于这些特点，用以上所说的任何一种分表方式都不合适，一没有固定的时效不宜用时间拆，二用户很多，而且还偏偏都是冷门，所以也不宜用版块(用户)拆。

　　哈希结构在上面有所提及，既然按每个用户不好直接拆，那就把一群用户归进一个表好了。

　　blog_aa

　　blog_ab

　　blog_ac

　　…

　　如上所说，md5取前两位哈希可以达到1296张表，如果觉得不够，那就再加一位，总数可达46656张表，还不够?

　　表的数量太多，要创建这些表也是挺麻烦的，可以考虑在程序里往数据库insert之前，多执行一句判断表存在与否并创建表的语句，很实用，消耗也并不很大。

　　主键：依旧要考虑的，在这个系统中，主键是用户ID+时间戳，单纯的时间戳或自动编号也能用，但查询时要记得带上用户名用于定位表。

　　四、总分结构

　　以上的这些结构，根据每个业务系统，能想出的估计还有很多。不过现在互联网业务越来越复杂了，有些时候，单一的拆分法还不能实现需求，需要几种拆分方案一起实施，多管齐下，这时候其中的逻辑会让人绕晕。我就开发过一个系统，仅仅是将哈希结构和时间结构混着一用，觉得逻辑就相当复杂。

　　所以，除了拆表之外，按最原始的单库单表，再建一个总表，是非常有利的架构。在这个架构中，每次往数据库会写入两倍数据，读取主要依赖拆表提升性能，总表用于实现拆表后难以实现的功能并且用于每天的定时备份;另外总表和分表还相互是一个完整的备份，任何一个分表损坏或数据不正常，都可以从总表中读到正确的数据并恢复，反之亦然。

　　在总分结构中，让人感到质疑的是总表的性能和可维护性。我的方案是总表可采用相对能保证稳定的一些服务软件和架构，例如oracle，或lvs+ pgpool+PostgreSQL，重点保证数据稳定;相对的，分表就用轻量级的mysql，重点在于速度。能够对总分表各采用不同的软件和方案，也是总分结构的一大特点。

　　总结：如何通过拆表来优化系统，最基本的是要按业务需求和特点分析。千万不可乱套，用错了工作量要加十倍噢。