求知若渴，虚心若愚！
居安思危，积极进取！
写在前面
前几天和一个创业公司的 CTO 聊天，他说他们团队 5 个后端开发，已经拆了 12 个微服务。我问他为什么要拆，他说"为了未来的扩展性"。然后我问他现在的 DAU 是多少，他说"几千"。
这让我想起很多年前见过的一个场景：一个刚起步的业务，还在验证商业模式，技术团队已经开始讨论服务网格和分布式追踪了。最后业务没做起来，技术架构倒是挺先进的。
微服务这几年被捧得太高了。很多团队在根本不需要的时候就开始拆服务，结果把自己搞得焦头烂额。今天想聊聊这个话题，不是说微服务不好，而是大部分团队真的不需要它，至少不是现在。
微服务的真实成本
开发成本的指数级增长
很多人以为微服务只是把代码拆开而已。实际上，从单体到微服务，你需要解决的问题是指数级增长的：
服务间通信：HTTP 调用、gRPC、消息队列，你得选一个。然后你会发现，本来一个本地函数调用，现在变成了网络请求。网络不可靠，你得处理超时、重试、熔断。原本简单的代码，现在要考虑各种边界情况。
最近在和几个技术管理者交流时，发现他们都在规划或已经落地了BFF（Backend for Frontend）架构。问为什么要做BFF，得到的答案惊人地一致："解耦前后端"、"提升开发效率"、"这是最佳实践"。
但当我问："你们团队有多少后端开发？前端开发呢？"，答案通常是"后端6-8人，前端3-4人"。这让我意识到一个问题：大部分团队上BFF，可能不是因为真的需要，而是因为"别人都在用"。
我想聊聊这个话题，不是要否定BFF的价值，而是想说：很多团队高估了BFF的收益，低估了它的成本。
BFF真正解决的问题
先说清楚，BFF不是伪需求。它在特定场景下确实有价值：
场景一：多端适配。你的后端API是为Web设计的，现在要支持移动端、小程序、IoT设备。不同端的数据需求、交互逻辑差异很大，用一套API很难搞定。这时候BFF可以为每个端定制API，后端保持稳定。
场景二：聚合调用。前端一个页面需要调用5-6个后端服务，串行调用太慢，并行调用又要处理复杂的依赖关系。BFF可以在服务端聚合这些调用，减少前端的复杂度和网络开销。
最近看到一个问题："全栈工程师是不是什么都要会？"下面的回答分成了两派，一派说全栈就是要前端后端数据库运维都精通，另一派说全栈是个伪概念，啥都会等于啥都不精。
两边都有道理，但我觉得都错了重点。
做了很多年全栈，从后端写到前端，再到带团队做架构，我的观察是：大部分人误解了全栈工程师的核心价值。全栈不是让你成为技术全才，而是给你一个完整的视角去理解系统、做决策、解决问题。
追求全能是个陷阱，追求全局观才是正道。
全能是个伪命题
先说个真实场景。
在金融业务中，经常会遇到性能问题。前端说页面慢是因为接口慢，后端说接口慢是因为前端请求太多，DBA说数据库压力大是因为查询写得烂，运维说服务器资源不够要扩容。
这时候如果你是个"全能型"全栈，你会怎么做？去优化前端的渲染逻辑、重写后端的查询语句、调整数据库索引、然后去研究服务器配置？
听起来很厉害，但实际上这是在用战术上的勤奋掩盖战略上的懒惰。
真正的问题可能是：这个需求本身就不合理，或者整个架构设计有问题。
前几天团队来了个新人，看到我们的CR流程后很兴奋："你们的Code Review好规范啊，每个PR都要两个Approver才能合并。"我笑了笑没说话。
因为我知道，这套看起来"规范"的流程，实际上每天都在发生这样的事情：开发者提交一个几百行的PR，半天没人review；着急上线就去钉钉群里@几个人；被@的人打开看一眼，觉得代码没大问题就点了Approve；测试环境跑了一遍没报错，代码就合并了。
整个过程看起来很严谨，实际上谁也不知道这段代码到底干了什么。
大多数CR都是形式主义
我见过太多团队把Code Review当成一种"仪式感"——必须要有这个环节，但没人在乎它到底有没有效果。
最常见的场景是：PR提交后，reviewer们象征性地打开看一眼，扫过去没发现明显的bug或者格式问题，就点了Approve。至于这段代码的设计是否合理、是否有更好的实现方式、是否会给系统带来潜在风险，没人去深究。
为什么会这样？因为review代码比写代码累。
最近看到团队在讨论页面首屏加载优化，有人提出要把某个 10KB 的图片压缩到 8KB，说能省 20% 的体积。我突然意识到，前端性能优化可能是我见过的最容易被过度执行、也最容易做错方向的技术工作。
不是说性能优化不重要，而是大部分人根本不知道自己在优化什么，也不知道这个优化到底值不值得。
性能优化的第一个迷思：技术指标不等于用户体验
打开任何一篇性能优化的文章，你都能看到一堆指标：LCP、FCP、TTI、FID、CLS。这些指标确实有价值，但问题是，你真的理解这些指标背后的含义吗？
我见过一个团队花了两周时间把 FCP 从 1.2 秒优化到 0.8 秒，但实际上首屏还是白屏，因为真正有意义的内容要等接口返回才能显示。用户看到的"快"，和监控平台上的数字，完全是两回事。
LCP 优化≠用户感知快。LCP 是"最大内容绘制"，但如果你的最大内容是一张无关紧要的背景图，优化它有什么意义？用户真正关心的是"我能不能看到商品价格"、"我能不能点击购买按钮"，而不是你的背景图加载了多快。
前端圈对状态管理的执念，可能是过去十年最大的集体焦虑。从Flux到Redux，从MobX到Recoil，从Context API到Zustand，每隔一两年就会冒出一个"更简洁"的方案，然后大家又开始新一轮的重构和争论。
但我越来越怀疑一件事：我们在用前端的方式解决本不该存在的前端问题。
状态管理焦虑的根源
大部分前端开发者第一次接触Redux的时候，都会有类似的困惑：为什么一个简单的计数器需要写这么多代码？action、reducer、dispatch、connect，整整一套ceremony，就为了让组件拿到一个数字。
当时流行的解释是："这是为了可维护性。" 等项目大了你就懂了。
确实，等项目大了，我懂了。但我懂的不是Redux的好处，而是我们把太多不该放在前端的状态放在了前端。
举个真实场景：用户的投资组合数据。
前两天团队讨论新业务的技术方案,后端同学提议用 GraphQL,理由是"前端可以自己控制数据结构,不用频繁改接口"。我问了一句:"你们后端有多少人?"答:"3个人"。我说:"那别折腾了,RESTful 就够了"。
这不是第一次遇到这种情况。这些年做全栈,从后端写 API 到前端调 API 再到 BFF 层设计 API,见过太多技术选型上的执念。最常见的两个误区:一是觉得 RESTful 就是正统,必须符合所有规范;二是觉得 GraphQL 能解决前后端协作的所有问题。
事实上,这两个都不是银弹。
RESTful 的形式主义陷阱
大部分开发者第一次接触 API 设计,学的都是 RESTful 规范。GET 查询、POST 创建、PUT 更新、DELETE 删除,资源路径用名词不用动词,状态码要严格遵循 HTTP 标准。这些原则没错,但问题在于,很多人把它当成了教条。
前后端分离已经是前端圈的"政治正确"了。但最近几年，我观察到一个反常识的现象：不少团队在推进前后端分离几年后，又开始招聘全栈工程师，甚至把部分项目重新合并。
这不是技术倒退，而是对"分离成本"的重新认识。
前后端分离的三大隐形成本
大部分团队谈前后端分离时，强调的是"职责清晰"、"技术栈解耦"、"并行开发"。但很少有人提它的代价。
1. 沟通成本：从「对话」变成「会议」
以前一个功能，全栈工程师自己从前端写到数据库，遇到问题自己调试，半天搞定。
前后端分离后？先写需求文档，前后端对齐接口，联调发现参数不对，再开个会讨论，改完继续联调。原本半天的事，拉长成三天。
我不是说会议不重要，而是很多"会议"本质上是在弥补"认知鸿沟"——前端不知道后端为什么这么设计，后端不知道前端要什么。
金融业务尤其明显。理财产品的持仓逻辑，涉及到实时资产、历史收益、预期收益三种数据，前端需要合并展示。如果后端不理解前端的渲染逻辑，可能会返回三个接口；前端不理解后端的数据模型，可能会要求合并成一个接口但无法满足缓存策略。
这不是技术问题，是认知问题。
参考：https://hub.docker.com/_/mysql
官方文档是这样写的：
$ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=my-secret-pw -d mysql:tag
其中 some-mysql 是你想要的mysql容器名， my-secret-pw 是mysql的密码（用户名是root），tag MySQL 版本，没有的话默认是用最新的latest版本。
本地启动mysql容器可以参考：https://blog.csdn.net/weixin_44037416/article/details/117956869
博客是放在Amazon的EC2.
全程参考：http://imcn.me/html/y2012/11870.html
其中遇到文件权限的问题：
默认EC2的nginx和php-fpm的用户和用户组是www-data。但是我ubuntu的文件权限是quentin，所以php写文件没权限了。
所以为了使php-fpm和文件权限一致，配置如下：
修改php-fpm配置：sudo vi /etc/php5/fpm/pool.d/www.conf
user = www-data 改成 user = ubuntu
修改nginx配置：sudo vi /etc/nginx/nginx.conf
user www-data 改成 user ubuntu