没啥好嘲笑的，小白这东西，拦一个是一个。

小白如果自己愿意上网查找答案，发现原来可以轻松破解，那也是好事，那意味着小白也多少学到了一点点新东西。

所以其实拦的不是小白，是某种意义上的伸手党，F12 一按就想抄。同样都是小白，能自己找寻破解方法和不愿意找的还是不一样的。

aveline

朋友，我觉得真的高并发的话，可能你的问题首先不是出在 MySQL 上，而是 php-fpm 上……

当然我不知道你怎么部署的，如果真的若干机器堆住，一般 hold 住也没问题，当然真是这样的话那 Redis 啥的也不算事了。

毕竟不知道你的高并发首先有多高 - -#

切 CDN 是因为被 D 了么。。。

买，不要犹豫。
家里又不是没有这个条件。

@guijianshi01 哈哈哈，理解理解，我就这么过来的。我的做法不敢说是完美，也是一个一个坑才过来的血泪史。

最核心的，我称为核心功能接口，我是尽最大可能划分到最细的粒度，比如一个 auth，这类接口我设计的时候原则上是不直接暴露给前端调用的，因为直接暴露意味着给前端需要请求太多的内容，无论性能还是开发流程上都不可接受，前后端会打架的。

但这类接口也不绝对，某些高频，无法也无需改动的，比如授权，这种模式下我会适当直接传给前端。

然后核心功能接口写出来其实是为了给后端调用的，用来做各种业务接口组合。这里面也是血泪史，差点和后端打疯，后端说我几个 import 的事你非要我调网络请求的形式来（我们目前的能力只能以 RESTful API 的形式互相调用），包括业务接口不一次写完，而是写完再组合… 但最后后端发现，在不同的项目中，熬过前期后，往往重新组合包装一个接口提供给前端，会变的异常轻松。

当然这里也有 API 网关这个我 18 年年初才学到的概念的支援。包括我上面讲的模式里，其实在包装组合接口提供给业务用这件事上，前端突然发现他们也有能力直接调用以及做组合了，所以业务上其实突然变的相对好一些了。

但一个系统的总体复杂度是不变的，对应的，压力放到了我这边，我自己做的这个设计和决策，现在我要为统筹管理和理清这么多接口、模式进行负责，这个压力也大。可总比和大家一起开会分析那绕来绕去的业务逻辑还是要轻松一些的。

所以我写了这么多，其实也没有直接回答你的问题。全部写一起肯定是弊大于利，畏手畏脚，甚至逼不得已要重新写一个新的大的单体出来。拆开的不合理的话，又会东改西改，并且接口功能重复，模糊，界限不清。

但就我自己的经验而言，还是要拆，拆的时候优先提炼出核心的不变的东西，尽可能在少增加额外开发的情况下将接口复用组合提供出业务接口来。而且业务接口尽量不要由核心系统直接提供，一定要有个 API gateway 层，让这个层来承担接口的分发工作。 我们用的也不好，业务中有大量冗余接口，也有很多沉没的存在安全隐患的东西，这个以后早晚要慢慢解决。但小公司，四五个人的团队，只能先到这样了。

也是老生常谈的话题了，讲的其实挺没意思的。

说到底啊，这行业的业务变化啊，太快了。。唉，做的累。

这个我有话要说。

我就干过类似楼主领导的事，要求别人（最后因能力问题搁浅，后来重新慢慢尝试，小步慢跑）。

中间不同的项目里反反复复很多次。

目前我仍然持有和楼主领导接近的想法，但不再那么激进，会根据实际情况进行调整和妥协。

但从一个系统架构设计的角度来看，我仍然认为拆分利大于弊，包括这种有人认为的过度设计的部分。首先过度设计就是个并没有绝对标准的东西，怎样算是过度的设计？

在项目进度允许，团队成员能力足够的情况下，一个总体复杂度为 10 的东西，而这个复杂度其实是大致可以预见到的，比如 3 个月做出来这个东西，相对可控，但 3 个月后这个项目会变成什么样，怎么发展，我不可预知，不可控，那就不考虑那种做成运行几年，团队扩充到 20 人的事。 但这 3 个月内可能会有的变动，模块和组件的拆分，部署的调整，哪些事情我提前做是可以预留的，这个讲实话，我是觉得需要很深厚的经验积累的。而运用的恰到好处的话，对团队，项目都是有极大的好处。

也就是说，我并不赞同一上来把整体复杂度为 10 的单体应用拆成 10 个 复杂度为 1 的模块，但根据实际情况，拆成一个略小的复杂度为 5 的小单体+ 5 个复杂度为 1 的小模块，是不是会更有利于项目推进、迭代试错、能力培养呢？

而且在开发周期较长的项目里，不考虑因为拆分带来的额外复杂度的情况，就项目本身而言，经常是这么一个转换节奏：

5 +3 + 2
5 + 1 + 1 + 1 + 1 +1
4 + 1 +1 +1 +1 +1 +1
4+ 2 + 2 +1 +1
3 + 1 +1 +2 +1 +1 +1

也就是楼上有人说的那句话，合久必分，分久必合。楼主的领导可能有过度设计的嫌疑，但楼主这种一个大单体的思路其实也有些理想化了——什么项目都经不起变啊，变着变着就要了亲命了，尤其是前端这种没有好的工程化体系的地方（不管 webpack 有多强，vue 多好用，只要还是 js，就注定没有好的工程化的基因）。

当然，我说了也白说，领导最大，木已成舟，估计楼主应该已经吭哧吭哧的做了蛮久了……

@chaleaochexist 关于二次封装接口这事，其实对我这样的小团队来说怎么看都是 import 更划得来，大家都用 PHP，为啥想不开要给自己对自己用接口调用，但这事我还是坚持接口化。就我这边来说，接口化不会带来多少性能损失，却给我这样的小团队和外部合作留下了足够好的基础（我们经常有交叉形式的外包），甚至某些接口我们作为收费卖给隔壁同行们……

当然这里面我还有个出发点，是为了三年战略中，逐渐引入 Java 或者 Go 开发人员和目前的 PHP 栈混用，这时候通过接口通信的模块化意义就更大了，这是和我司实际情况有关。

所以你想学的是后端语言对吧？

语言好像不是差别很大，除非还想做单体应用，如果为以后考虑，Java 和 Go 都可以考虑下。

首先，实际页面存在多设备兼容这个问题，除非 UI 全给做到，否则 100% 还原度就没法做到。

我们现在暂时提倡的方法是不追求字面意义的 100%还原，而是由 UI 给出对元素兼具，字体大小等等的要求，详细到 font-size，元素在不同界面尺寸下的不同间距，然后前端只管照这个来堆上去。

既然是想深造，选个自己有基础有兴趣愿意攻关的，然后放心大胆的学吧。


我自己是大学本科，上一半跑路退学，现在三十多岁，然后现在从成人高考开始重新开始学习，选的不是自己现在做的开发和计算机有关的方向，但有我多年工作经验加成，我也有兴趣，希望四十岁的时候能小有所成。

实际操作中我们是这样。

一，有一组粒度极细，原子化的基础接口。

二，一部分常用的业务接口，对基础接口做二次封装。能满足 70% 的调用需求。

三，有 10%左右的需求因为目标简单明确，直接去了第一条里提的那些接口。

四，有一些临时项目需求，临时拼装一些小接口。

所以像你说的问题，我是绝对会拆出一堆各种 API 来的。

业务千变万化，所以我是要什么给什么，能拆分的 API 绝对拆开，不怕接口多，就怕接口改。改起来才是真要命，千丝万缕在一起。

业务 API 因为太多，所以时间久了会有重复功能的接口，我也毫不在意，因为这类接口只直接为一个业务服务，业务哪天变了或者撤了，老的接口也就没用了。

能，有变通方法，但不好用。

而且似乎也没必要这么用。

不是我喷，画像这个东西技术层面大家各有做法，但有没有可能，在现行的一些系统下这压根就是个不存在的东西。

很多人，喜欢一类事物，但希望有人推荐介绍给他其他类别的事物，不管喜欢不喜欢，在很多时候，我们喜欢尝试不一样的东西。

我总感觉，推荐系统做到最后，很多时候就是随机给。

非要说什么地方可以精确确认，那不是我不喜欢，而是明确强烈的『我不喜欢』，当用户表现出强烈的反感时，系统收敛点，不给推荐这类内容，那就是推荐系统善莫大焉了。

刨除掉不喜欢的，剩下的，random （）吧。

我最近在一个做的系统里用了一个古早的方法。（当然我以前不知道，或者是用的太少忘了。）

<div data-include="header" class="headerBox"></div>

然后 js 部分

<!--下面的 js 用于引入模板文件-->
<script>
$(function() {
var includes = $('[data-include]');
jQuery.each(includes, function() {
var file = 'views/' + $(this).data('include') + '.html';
$(this).load(file);
});
});
</script>

模板文件路径为 views/header.html

可参考。

这个方法其实不是真正的组件化，但遇到 JS 做处理的时候，其实会有不少问题。
但如果只出静态页面，就要你写个样子出来的话，JS 主要处理一些 DOM 的话，这个方法能节省不少劳力。
又避免 iFrame 的一些问题。

风扇大？