微服务的节点多了真的很不好么?宏服务是什么东西?
今天看到这个
https://my.oschina.net/DeveloperFront/blog/4651920
新的专有名词被发明出来“宏服务”,这是什么东西?取代微服务的东西?微服务节点多了真的很不好么?
各位的主管 web 项目,大了之后有没有考虑微服务,还是考虑过走“偏门”的方法?还是到时候看情况着来?
今天看到这个
https://my.oschina.net/DeveloperFront/blog/4651920
新的专有名词被发明出来“宏服务”,这是什么东西?取代微服务的东西?微服务节点多了真的很不好么?
各位的主管 web 项目,大了之后有没有考虑微服务,还是考虑过走“偏门”的方法?还是到时候看情况着来?
本质上还是业务和架构、开发效率、运维成本的综合考虑
这个不是说微服务方向上有问题,而是其实整合部分微服务为宏服务在维护性上会好很多。
多少人喷我啊,多少人笑话我啊。v2 桑多少人和我吵啊。
现在呢
上微服务要么面向简历要么面向升职
只不过大部份技术人员为了恰饭,天天吹
所会拆出 100 层调用的那些人,根本没去了解微服务要解决的问题,为了微服务而微服务。
ABC 三个模块,在巨石里面他们是三个互不相干的业务组件,其中一个升级会导致另外两个业务也会产生变更,其中一个代码有 bug,会影响另外两个业务程序正常运行。为了解决这个问题,才把他们拆开三个微服务。而不是因为 A 通过函数调用 B,B 通过函数调用 C,就把他们拆成微服务。
微服务的核心优势就是把系统复杂度从开发转移给了运维,而运维靠 docker 、CI/CD 、k8s 这些技术解决了开发甩过来的复杂度,所以大家都很快乐。但如果你没有能力搞定运维,就会被干趴下,于是微服务对你就不是什么好事了。在服务拆分上面也一样,拆得不好,维护起来比单体更麻烦。
所以,是不是要上微服务,不是看规模大小,也不是看行业,而是看团队有没有这个能力。有能力就上,没能力就不要赶时髦硬上了。