lotusp 最近的时间轴更新 lotusp 最近的时间轴更新 |
lotuspV2EX 第 560837 号会员，加入于 2021-11-05 17:13:04 +08:00 |
https://www.maguangguang.xyz
| 为什么每个微服务要有自己独立的数据库？ 程序员 • lotusp • 27 天前 • 最后回复来自 pastor | 63 |
| [文章是自己的好] 技术博客也是写作，一样要把文章写好 分享创造 • lotusp • 41 天前 • 最后回复来自 lotusp | 6 |
| 如何识别和定位软件架构的问题？
1 程序员 • lotusp • 50 天前 • 最后回复来自 xuanbg
|
3 |
| 充值未到账，请帮忙确认，谢谢 Chamber • lotusp • 57 天前 • 最后回复来自 Livid | 1 |
| 分层架构，经典却很难做好 程序员 • lotusp • 66 天前 • 最后回复来自 RainCats | 10 |
| 微服务架构盛行，微服务分分合合很常见，大家的微服务系统都是如何设计和演进的？ 程序员 • lotusp • 73 天前 • 最后回复来自 haolongsun | 16 |
| 微服务架构下大家都在实践 BFF，你的 BFF 都有哪些问题？ 程序员 • lotusp • 77 天前 • 最后回复来自 lotusp | 14 |
lotusp 最近回复了
27 天前 回复了 lotusp 创建的主题 › 程序员 › 为什么每个微服务要有自己独立的数据库？ |
@pastor 没有谁做技术是千篇一律的，如果你读一篇文章就认为这是唯一的架构方案，不需要根据实际情况做调整，也需要自省一下，写文章是分享思路和经验，每家的业务复杂度、技术实力、现实情况都不一样，某些技术选型有什么优势，有什么劣势，这是我们要讨论分享的。
“中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了”
---- 这观点就很武断，滴滴、阿里哪个业务稳定，哪个变化不快，为啥非要稳定的传统企业才能用中台
很多中台搞不起也不单纯是技术的问题，组织结构上就很难支持
“中台也一样，坑很多团队，真正适合的搞法是从实际出发，除非你家业务成熟稳定需求不怎么变了比如很多传统企业级的产品，否则就别鼓吹什么不知道实事求是的方法论了”
---- 这观点就很武断，滴滴、阿里哪个业务稳定，哪个变化不快，为啥非要稳定的传统企业才能用中台
很多中台搞不起也不单纯是技术的问题，组织结构上就很难支持
27 天前 回复了 lotusp 创建的主题 › 程序员 › 为什么每个微服务要有自己独立的数据库？ |
@pastor 上来就一句“像楼主这种只知道人云亦云拿来主义的垃圾架构师”，这么直接的攻击不叫人身攻击，我也是很难理解你的思考方式。没想人身攻击说话就注意表达方式，请“好好说话”。
27 天前 回复了 lotusp 创建的主题 › 程序员 › 为什么每个微服务要有自己独立的数据库？ |
@pastor #53 看了你的很多留言，确实是个天生不会好好说话的人，讨论技术就说技术，别夹枪带棒的人身攻击，要是真不会好好说话就少说
技术没有对错，看你用的对不对，微服务这么多年，有人成功，有人失败
中台也是有人成，有人败，搞不懂关键问题在哪就开始整不死才怪
你搞不定不能一棒子打死就说技术不行
@qwe520liao #33 楼说的很中肯，也是经验之谈，微服务目的是解耦，提升弹性，不是随便拆成几个进程就完了
技术没有对错，看你用的对不对，微服务这么多年，有人成功，有人失败
中台也是有人成，有人败，搞不懂关键问题在哪就开始整不死才怪
你搞不定不能一棒子打死就说技术不行
@qwe520liao #33 楼说的很中肯，也是经验之谈，微服务目的是解耦，提升弹性，不是随便拆成几个进程就完了
36 天前 回复了 Haixiang 创建的主题 › 程序员 › 分享你正在使用的笔记软件 |
41 天前 回复了 lotusp 创建的主题 › 分享创造 › [文章是自己的好] 技术博客也是写作，一样要把文章写好 |
@sevdot 看了你的博客，最近输出很多，高产赞一个
41 天前 回复了 lotusp 创建的主题 › 分享创造 › [文章是自己的好] 技术博客也是写作，一样要把文章写好 |
@dann73580 多谢分享
41 天前 回复了 lotusp 创建的主题 › 分享创造 › [文章是自己的好] 技术博客也是写作，一样要把文章写好 |
58 天前 回复了 coala 创建的主题 › Java › 微服务方案中 Socket 和 WebSocket 如果实现多实例负载呢? |
在微服务上下文里，不管是短连接还是长连接，前端打交道的后端应该都不止一个
可以专门为长连接建立一个 gateway ，这一层对前端是长连接，对后端可以长连接，也可以短连接
后端服务升级重启做到优雅退出，就不影响前端
可以专门为长连接建立一个 gateway ，这一层对前端是长连接，对后端可以长连接，也可以短连接
后端服务升级重启做到优雅退出，就不影响前端
@levelworm 新官上任三把火
73 天前 回复了 lotusp 创建的主题 › 程序员 › 微服务架构盛行，微服务分分合合很常见，大家的微服务系统都是如何设计和演进的？ |
@devswork 讨论微服务拆分时机，从问题出发更好，如果单体架构也没有啥问题，当然也没必要非要引入微服务，徒增复杂度。
微服务的好处很多，但确实实施要求也高，所以在问题足够复杂的时候比较适合，比如：
1. 业务非常复杂，业务知识就多，放在一个单体服务里，知识的传递和上手本身就很困难。
2. 代码量很大，大几十万或上百万行代码，编译、排查问题都很耗时。技术上我们可以通过一些包级别的隔离尽量做到清晰，但实际操作难度也是不小的，毕竟开发人员水平各不相同，日常开发实现功能优先级更高，写代码图方便的也不在少数，所以单体越大内部耦合越严重，表现出来线上的稳定性非常差。
3. 团队逐渐变大，一起写代码，在一个单体上开发，提交 merge 的冲突比较多。人多了分小组，即便每个小组可以有专门的职责，在一个单体上开发，可以触碰到所有的代码，改动的冲突也会比较多。
开弓没有回头箭，单体往微服务迁移，还是要多方权衡，是否足够复杂，是否团队自己能搞定拆分之后的各种问题：
1. 尽量多的自动化，CI/CD ，自动化测试等
2. 上线后排查问题涉及多服务会更复杂，监控等手段得跟上
3. 多服务之间的契约稳定性保证，避免单方随意修改契约
4. 分的越多，职责越多，团队是否有足够的人来管多个服务
微服务的好处很多，但确实实施要求也高，所以在问题足够复杂的时候比较适合，比如：
1. 业务非常复杂，业务知识就多，放在一个单体服务里，知识的传递和上手本身就很困难。
2. 代码量很大，大几十万或上百万行代码，编译、排查问题都很耗时。技术上我们可以通过一些包级别的隔离尽量做到清晰，但实际操作难度也是不小的，毕竟开发人员水平各不相同，日常开发实现功能优先级更高，写代码图方便的也不在少数，所以单体越大内部耦合越严重，表现出来线上的稳定性非常差。
3. 团队逐渐变大，一起写代码，在一个单体上开发，提交 merge 的冲突比较多。人多了分小组，即便每个小组可以有专门的职责，在一个单体上开发，可以触碰到所有的代码，改动的冲突也会比较多。
开弓没有回头箭，单体往微服务迁移，还是要多方权衡，是否足够复杂，是否团队自己能搞定拆分之后的各种问题：
1. 尽量多的自动化，CI/CD ，自动化测试等
2. 上线后排查问题涉及多服务会更复杂，监控等手段得跟上
3. 多服务之间的契约稳定性保证，避免单方随意修改契约
4. 分的越多，职责越多，团队是否有足够的人来管多个服务
Select Language