麻痹马一龙向micro service 宣战了

[hci]

CTO 要对技术有自己的口味。只要风格一致，其实用什么口味并没有那么重要。每种技术风格有自己的优缺点，知根知底，就可扬长避短。

可惜大多数管技术的不懂技术，只知跟风。

[赖美豪中]

不是绝大多数，是100% for sure, 什么agile, microservice都是一群jb废材mba为了显得有用从垃圾堆里捡回来的垃圾概念

关键是其实绝大部分商业公司其实没那么复杂需要到处用Micro Service。都是over engineering.

[赖美豪中]

不懂技术不要紧，但是大部分不懂技术心理慌，为了刷存在感，他们需要一堆垃圾来证明自己有价值

CTO 要对技术有自己的口味。只要风格一致，其实用什么口味并没有那么重要。每种技术风格有自己的优缺点，知根知底，就可扬长避短。

可惜大多数管技术的不懂技术，只知跟风。

[coltzhao]

不是绝大多数，是100% for sure, 什么agile, microservice都是一群jb废材mba为了显得有用从垃圾堆里捡回来的垃圾概念

never say never.

一看你就不是两种都用过。

[GaussNewton]

microservices的目的是让一大群平庸的工程师管理一个系统，怕他们出错所以分成独立的小功能模块，真的牛人来做的话确实用一个或几个大模块就行了，但是这样公司太依赖少数人了

[retry]

microservices的目的是让一大群平庸的工程师管理一个系统，怕他们出错所以分成独立的小功能模块，真的牛人来做的话确实用一个或几个大模块就行了，但是这样公司太依赖少数人了

这是连 microservice 解决什么问题都没搞清楚， 就出来喷。 LOL

[GaussNewton]

这是连 microservice 解决什么问题都没搞清楚， 就出来喷。 LOL

喷你是平庸工程师了？别这么自我代入啊

[pda]

听说rate limiter和2FA micro service 都给关了，太欢乐了

[faq]

听说rate limiter和2FA micro service 都给关了，太欢乐了

那岂不是能期待更多谣言。不知道又有多少人可以造谣操纵股价了

[hahan]

microservice确实是狗屎。你看狗脸都不搞这一套。尼玛脸的一个复杂GraphQL返回的东西要是拿microservice搞，得发几百个network request。

你懂个鸡巴
搞monolithic 需要强大的人力 不光是人多 还得牛人把关
马斯克这个傻逼 等他和普京的往来被查清 看他怎么蹦跶

[CutPaste]

把大型service break down，每个小型服务可以管理自己的开发和上线流程，减少相互依赖，降低线上出错的几率

但体系复杂化，管理起来更麻烦，出问题的概率其实更高了

尼玛，这概念上世纪70年代前就有了。

结果要等几十年后才火起来，并且被指定。

另外，Micro Service 这个概念，

任何写了许多程序的都应该知道是正确设计布局。

这概念其实半世纪前就有了。任何真码工都该有。

真码工是指写了无数须快速开发和实时应用程序的。

高效写好需求复杂的程序，秘诀从来是Divide&Conquer。

一个庞大复杂的程序本该由无数极小的标准化微程序合成。

这个概念，任何写了许多程序的聪明程序员都该悟出来的。

今天所谓先进概念和方法，绝多数只是旧酒装新瓶而已。

并且绝多数是实际应用经验加理性思考后的必然认知。

照理说，绝多数爱思考的程序员应该都能独立的发现。




.

[CutPaste]

感谢解释

目测马一龙能带来IT圈优化新风潮

既然微服务，微程序化，控制层次越少越好。

设计流程时也应该尽量用最直接的指挥。

最好的程序设计，也必然是最容易DEBUG。

程序最容易DEBUG，必然也是最容易理解。

错误一出现，就知道是那个微程序制造的。

由于是微程序，所以非常易懂，也能迅速修正。

这里的微程序是指微小，功能专一的程序。


.

[CutPaste]

Sounds like to good idea. Why not working?

The bugs are swept into and covered up inside the black boxes.

My guess.



.

[CutPaste]

那说明问题没分割好，分割清楚，不会有问题。

属实。




.

[CutPaste]

microservices的目的是让一大群平庸的工程师管理一个系统，怕他们出错所以分成独立的小功能模块，真的牛人来做的话确实用一个或几个大模块就行了，但是这样公司太依赖少数人了

我就特别喜欢小模块，独立的，越小越好。

回报是程序改进灵活性和DEBUG的效率。

越是复杂的应用，这方面的优势越明显。




.

[faq]

尼玛，这概念上世纪70年代前就有了。

结果要等几十年后才火起来，并且被指定。

另外，Micro Service 这个概念，

任何写了许多程序的都应该知道是正确设计布局。

这概念其实半世纪前就有了。任何真码工都该有。

真码工是指写了无数须快速开发和实时应用程序的。

高效写好需求复杂的程序，秘诀从来是Divide&Conquer。

一个庞大复杂的程序本该由无数极小的标准化微程序合成。

这个概念，任何写了许多程序的聪明程序员都该悟出来的。

今天所谓先进概念和方法，绝多数只是旧酒装新瓶而已。

并且绝多数是实际应用经验加理性思考后的必然认知。

照理说，绝多数爱思考的程序员应该都能独立的发现。




.

属实。而且microservice 可以根据需要scale

[nonce]

道者反之动，工程组织尤其如此。码农不管有意无意，总会把一些设计原则放大变成shit山，然后拥屎自重。

这次一龙忍无可忍，捏着鼻子削藩收了兵权

[tang21]

说的到位！精彩！！
你看各种问题的见解都很犀利！

既然微服务，微程序化，控制层次越少越好。

设计流程时也应该尽量用最直接的指挥。

最好的程序设计，也必然是最容易DEBUG。

程序最容易DEBUG，必然也是最容易理解。

错误一出现，就知道是那个微程序制造的。

由于是微程序，所以非常易懂，也能迅速修正。

这里的微程序是指微小，功能专一的程序。


.

[tang21]

re

尼玛，这概念上世纪70年代前就有了。

结果要等几十年后才火起来，并且被指定。

另外，Micro Service 这个概念，

任何写了许多程序的都应该知道是正确设计布局。

这概念其实半世纪前就有了。任何真码工都该有。

真码工是指写了无数须快速开发和实时应用程序的。

高效写好需求复杂的程序，秘诀从来是Divide&Conquer。

一个庞大复杂的程序本该由无数极小的标准化微程序合成。

这个概念，任何写了许多程序的聪明程序员都该悟出来的。

今天所谓先进概念和方法，绝多数只是旧酒装新瓶而已。

并且绝多数是实际应用经验加理性思考后的必然认知。

照理说，绝多数爱思考的程序员应该都能独立的发现。




.