拆你妹的微服务

你笑起来真懆淡:
分布式单体，有机结合了分布式和单体的所有缺点[doge]

【回复】回复 @崽卖爷田不心疼 :微服务想要做好单体复杂的多，技术层面和业务层面都要考虑，熔断降级，全链路追踪，如何拆分业务领域，如何把同步调用改为异步，设计防腐层解藕等等，这些东西不是几个人的团队能负担得起的，如果仅仅把单体的模块做成微服务，模块调用改成rpc，那基本上就掉进分布式单体的坑里了，稳定性，性能还不如单体，服务之间耦合，甚至启动顺序有要求，唯一的好处就是横向拓展，完全是得不偿失
【回复】说下我的体会： 涉及到业务逻辑的一律不微服务化，尤其是涉及到事务，只把工具型功能微服务化，比如发短信，4要素认证，文件处理之类。业务如果没有明显依赖拆分两个大服务，分别部署，rpc调用单向依赖，避免微服务化。
【回复】人才啊，这个描述笑死我了。仔细想想真是这个事。
斯启余:
[吃瓜]小公司又微服务，然后又前后端分离，结果只有一个人写。最搞笑的是只有一个服务器

【回复】前后端分离了，人没分离；服务拆分了，人没拆分[doge]
【回复】回复 @bili_辰光 :现在前后端很难不分离吧，主流技术都是前后端分离
【回复】还有小公司面试也一样，什么牛马项目都跟你讲高并发[doge]
葛多尔派普:
太真实了，作为干过运维和开发的深有体会，现在的主流情况是微服务的同一个项目都是一个团队在开发和维护，数据库特么还不一定拆分，最无语的是大部分微服务项目企业生产级别不会真正使用分布式事务（至少我开发过和运维的4个微服务项目都是这个情况，有一个还是用户3亿+的平台），MQ异步是无法有效解决事务问题和数据一致性问题的，死信队列最后不还是数据不一致，还有超时问题不确定状态更麻烦，可能有投诉人工然后走流程改生产数据补偿等流程，都是采用补偿方案或者是人工，对账稽核日志系统日志数据库等，如果是项目内部数据和服务真没必要为了拆而拆，除非是业务耦合性很低可以拆分，再就是跨部门的和外部接口可以采用异步，个人观点不代表普遍情况，目前工作看下来微服务的事务问题导致数据不一致维护产生的各种人工补偿方案稽核系统才是成本最高的地方

【回复】确实所谓的最终一致性带来的成本很高。要想强一致就得分布式事务，分布式事务性能又拉跨了。
【回复】解释一下为什么数据库不拆分用户3亿+的平台数据库无压力，其实刚开始是无压力的，数据多了就有压力，数据库拆分自然有无侵入业务的解决方案，业务拆分（垂直拆分）风险很高，责任太大；最后使用物理分库（水平拆分）分24个库，测试单表10亿数据毫无压力
bearfight:
感觉这说的就不是微服务，最多算个分布式单体项目。

【回复】把感觉去掉，其实up把微服务理解成分布式了，实际上分布式就是靠多台计算机拆分业务提高性能的，而微服务并不要求多台计算机部署，可以单机部署，注重的只是服务拆分成独立开发、测试、部署的小服务。并不要求多台服务器部署。
【回复】就一个是理论，一个是落地实现
【回复】啥微服务，小公司单体服务干到底，分模块自己干自己的
游荡的码农:
最后几十个微服务都部署在一台机器上[doge]

【回复】别说了别说了，我干过两个项目都是这样，十几个服务都在一个机器上面，用户也不可能会多买服务器的。
JUST_ROOG:
这就是典型的java架构师思维，估计是只写java，所以很难跳出他的情景思考。 举个典型的例子，我面过一个游戏相关业务的小公司，他们的技术团队大概二十人上下。游戏业务团队有六七个。写Cpp和C#，商城业务写php,java和lua(nginx和redis用),web前段主要写ts。厂不大，并发也不算高，高峰时段也就几十万qps但是波动很大。 在这种场景下如何把不同预言栈，不同的服务环境整个成一个大单体或者jar包呢？他们7成以上的业务甚至和java没多大关系。 微服务的点在于你的应用维护的人力成本是否受限于传统的部署方式。只依靠典型的devloper思维是无法理解微服务架构思路的。即便是小厂也经常有根据不同的实际需求选择不同技术栈的情景，放弃开放式的心态是很可怕的自我束缚。

【回复】确实，灵活根据不同语言特性处理业务，没必要只用一门语言，不同语言开发的服务使用一定的协议通信即可
Sail_Wang:
[doge]实际上需要微服务架构设计，都是需要开发一个大项目，这个项目又N个团队，但你们只需要治理好自己的微服务就行了。小公司，基本没有这种大项目需求，最逆天的是一个管理项目也用微服务架构设计，还不面向互联网，实例还只有一台，纯属为了拆而拆。

【回复】说对了，就是我们公司现在架构
【回复】主因还是因为培训班要挣钱，人家在网上刷流量，你不搞微服务人家就该搞你了
十九去虚幻取经:
是不是只要一键三连，就可以获得这位又帅又有实力的UP主的课件呀[星星眼][星星眼][星星眼]

【回复】私信我，把邮箱发过来，我给你发文档。
水水的金小乖:
说的实话。 当年毕业后第一个工作是我导师给的 继续在学校写程序。 一共就几百个学生用的小系统，我直接django+默认的sqlite在单机上搞定。 多一分都没必要。 你要真想玩，用txt当数据库都能跑得起来。 但后续面试的时候就得开始瞎吹啦[doge][doge]

【回复】这不是面试造火箭的底层原理吗。[笑哭]
风和日丽-:
说白了适合自己才是最好。 大部分中小企业来说，一台高性能的服务器基本上就满足需求了。搞这搞那，很多时候都是邯郸学步。

taiwa3:
大厂拆微服务是有足够的员工分工维护。几个员工拆一堆微服务，自己给自己找不痛快。

【回复】没有困难制造困难也要上。[吃瓜]
TumaTuka:
整一堆服务治理 服务注册 稳定性可靠性 监控 日志 追踪[滑稽]

【回复】是啊，需要一大套东西。要做就做全套服务。[滑稽]
空指针exc:
现在我在做的就是这个，把一个大的服务拆成多个，每个服务只负责一个业务。但是TMD都是我一个人写一个人维护[doge]

【回复】你好，架构师，[doge]你这还能看到全部源码，我之前公司就只能看到自己负责那块的源码，不如运维[doge]，运维没事还看我们源码学习
【回复】[doge]不幸言中了，都是你一个人扛下了所有。
【回复】自己给自己找麻烦[笑哭]
ScottMarvel:
像to B端的小公司，你要是不用微服务，你招标都招标不到[笑哭]，总要有点噱头[笑哭]

【回复】精辟 我们就是 哈哈，技术上要有亮点 与时俱进
HowardYourDad:
前两天客户的一个接口挂了，修了一周没修好，原来是部署在办公室pc上的k8s挂了，重启服务起不来[doge][doge][doge]

咸鱼在翻身_:
以我有限的经验来说，功能组件化、面向接口做依赖，比拆这拆那要重要的多。