@jones2000 期待有成功的案例，未来确实很多工作 AI 都可以搞定。
不过我觉得分析决策性的脑力劳动，AI 短时间还很难完成

@fengjianxinghun @leimao Tech Lead 不管人但应该要做方案分配任务吧，如果完成的不好是不是要自己上去解决问题？

@MindMindMax 这好像是一直以来都有的问题，教会徒弟，饿死师傅
不过从 TL 个人角度，培养下面的人也是为了帮自己干活，不要累死自己

@yangxin0 同感，大部分 TL 从开发开始承担一部分管理工作，就开始转的比较过，大部分时间都在开会，不参加方案设计，不参加 CodeReview 。我觉得确实有大环境的问题，但 TL 得有意识改变自己的这个状态，做好时间管理，把技术的事情管起来，毕竟 TL 的核心竞争力在技术。

@pastor 没有谁做技术是千篇一律的，如果你读一篇文章就认为这是唯一的架构方案，不需要根据实际情况做调整，也需要自省一下，写文章是分享思路和经验，每家的业务复杂度、技术实力、现实情况都不一样，某些技术选型有什么优势，有什么劣势，这是我们要讨论分享的。

“中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了”
---- 这观点就很武断，滴滴、阿里哪个业务稳定，哪个变化不快，为啥非要稳定的传统企业才能用中台
很多中台搞不起也不单纯是技术的问题，组织结构上就很难支持

@pastor 上来就一句“像楼主这种只知道人云亦云拿来主义的垃圾架构师”，这么直接的攻击不叫人身攻击，我也是很难理解你的思考方式。没想人身攻击说话就注意表达方式，请“好好说话”。

@pastor #53 看了你的很多留言，确实是个天生不会好好说话的人，讨论技术就说技术，别夹枪带棒的人身攻击，要是真不会好好说话就少说

技术没有对错，看你用的对不对，微服务这么多年，有人成功，有人失败
中台也是有人成，有人败，搞不懂关键问题在哪就开始整不死才怪
你搞不定不能一棒子打死就说技术不行

@qwe520liao #33 楼说的很中肯，也是经验之谈，微服务目的是解耦，提升弹性，不是随便拆成几个进程就完了

如果用 markdown 快速记录想法和文字，Effie 是个不错的选择，可以快速记录下来
还能复制文字，以图片的形式分享
缺点就是现在还不支持图片
https://www.effie.co/

@sevdot 看了你的博客，最近输出很多，高产赞一个

@dann73580 多谢分享

@yukang 12 年的写作者，厉害了👍🏻
非常认同博客里的一句话：
“我们常说写作即思考，并不是写作让人更丰富，而是思考让人更丰富。”

在微服务上下文里，不管是短连接还是长连接，前端打交道的后端应该都不止一个
可以专门为长连接建立一个 gateway ，这一层对前端是长连接，对后端可以长连接，也可以短连接
后端服务升级重启做到优雅退出，就不影响前端

@levelworm 新官上任三把火

@devswork 讨论微服务拆分时机，从问题出发更好，如果单体架构也没有啥问题，当然也没必要非要引入微服务，徒增复杂度。

微服务的好处很多，但确实实施要求也高，所以在问题足够复杂的时候比较适合，比如：
1. 业务非常复杂，业务知识就多，放在一个单体服务里，知识的传递和上手本身就很困难。
2. 代码量很大，大几十万或上百万行代码，编译、排查问题都很耗时。技术上我们可以通过一些包级别的隔离尽量做到清晰，但实际操作难度也是不小的，毕竟开发人员水平各不相同，日常开发实现功能优先级更高，写代码图方便的也不在少数，所以单体越大内部耦合越严重，表现出来线上的稳定性非常差。
3. 团队逐渐变大，一起写代码，在一个单体上开发，提交 merge 的冲突比较多。人多了分小组，即便每个小组可以有专门的职责，在一个单体上开发，可以触碰到所有的代码，改动的冲突也会比较多。

开弓没有回头箭，单体往微服务迁移，还是要多方权衡，是否足够复杂，是否团队自己能搞定拆分之后的各种问题：
1. 尽量多的自动化，CI/CD ，自动化测试等
2. 上线后排查问题涉及多服务会更复杂，监控等手段得跟上
3. 多服务之间的契约稳定性保证，避免单方随意修改契约
4. 分的越多，职责越多，团队是否有足够的人来管多个服务

@Chinsung 赞同，另一个角度还是要看复杂度，业务复杂度，团队大小（开发协作的复杂度），是否有复用需求
业务复杂度一般，团队不太大，协作也没有任何问题，单体的优点还是很多的

@dudubaba #13 感谢分享，看来方案实施是需要团队成员都认可的，否则很难推下去

@LichMscy #11 如果是拆分现有的后端服务，可以新建 BFF ，先将后端 API 都经过 BFF 透传。然后根据领域建模等手段分析后端服务该拆成几个微服务，当前后端服务可以作为一个核心微服务保留下来，其他的逻辑拆出去新建服务。这样的话 BFF 作为一个后端微服务拆分的隔离，可以通过 Toggle 等决定走原有的后端 API ，还是新拆出来的新 API ，切换也可以相对顺利可控一点。

@LichMscy 一般情况下 BFF 应该主要是为前端服务，不太需要存储数据，请问您这边 BFF 的数据表主要是存些什么样的数据？

@RiceMarch 应急响应能力能详细说说吗？是 BFF 发生问题时快速解决效率不足，还是 BFF 快速响应业务的需求，开发效率上不去？