其实很奇怪，为什么都要用分布式、微服务等等等等呢？

[罗道人J]

大概五六年没找过工作了吧。可能是我过时了？最近去翻了翻招聘要求，发现几乎所有的公司，招聘的时候都要求要做过分布式，做过微服务，等等等等。很有前几年，随便哪家公司，都要求程序猿会大数据一样。。

我承认，分布式/微服务等等，都是好东西。真的有这么多分布式/微服务的要求么？

----------------------------------------------------我与分布式--------------------------------------------------------

对于分布式，有一阵子很感兴趣，也去研究过zokeeper，想要用他来玩玩。我当时的公司是做数据服务的。有对政府，也对互联网。对政府的话，访问量不会高，自然不需要这些东西。对互联网，我知道互联网的数据体量，是会有上千万，上亿等等这些的，很正常。但是我们公司这边，访问量其实还行，搞了搞缓存，负载均衡，其实觉得也没啥问题，就没再考虑再去麻烦搞分布式了。。

离职以后，开始单干了。前阵子和朋友做了个房地产保险类的项目，功能简单直接，预期的注册用户。。。。几千？上万？地产保险类的APP，访问量当然更低，有个几十的并发就不错了。。然后对方公司的技术老大，就拼命跟我要求什么分布式开发啊，跟我提访问压力啊等等，搞的很火大，给怼回去了，可能是因为这个吧，对分布式什么的，印象很不好。

----------------------------------------------------我与微服务--------------------------------------------------------

和微服务的联系，更少一些。虽然自己去研究过springboot，springclood，知道它是用来干嘛的，也会用，但是从来没在自己的项目里面真正用过它们。。其实说到底，微服务不就是多少年前，程序模块化的一种表现么？除了真正的重量级的应用，有谁会把程序切割成几块来玩？

有人说，随着技术的发展，现在成熟了，所以。。。等等等等。

但是，和整体架构相比，微服务始终导致开发和维护的复杂性。状态判断、事务控制、程序沟通，等等可预见的问题。

为什么还是所有人都要往微服务上凑呢？

不否认，它有它的优点，比如独立开发、独立部署等，在升级部署的时候，也不会影响到其他应用，这些其实我都知道。比如微信啊支付宝啊阿里啊淘宝啊等等，一大堆东西，用它们来做，是会很好很好的。

但是对于绝大多数应用，尤其是企业级应用，普通APP应用来说，用起来真的能够抵消它所带来的麻烦么？


-------------------------------------------------------完毕--------------------------------------------------------

最近想在找个工作，清闲点的，混混日子。结果到网上去看了看招聘信息，几乎所有的招聘，都要求，做过分布式、微服务等等。。

在想，难道所有公司的数据体量、访问量，都已经达到这个程度了么？还是说，只是个噱头啊？




----------------------------------------------------补充一个，我与大数据-----------------------------------------------------------

与大数据的缘分，会更深一些。因为毕竟在一家号称大数据的公司，呆过几年的。不知道是我对大数据的理解有问题，还是说本来就是这样。从某一年开始，所有公司都开始号称自己是大数据了。

我们原公司，数据处理的量级倒是不算小，千万级的数据吧。但是说真的，没有什么大数据啊等等，其实还是数据的统计分析，只是数据量级大了而已。。。

另外就是，其实和很多朋友，同事，都聊过这个话题。。都在号称大数据。。但是真正用什么数据挖掘，智能分析的，有那么一两个吧。

真的有那么多公司在做大数据么？

[咸哼酒家]

让楼主失望了，我不是个妹子，虽然我也想要有个妹子 现在软件的整体发展趋势是为了更好的服务于业务，以前强调瀑布模型，现在需求他妈的老是变，客户都不清楚要啥 光web端不够，还要APP，还要小程序，要响应好刷新快，还得好看酷炫、洋气上档次 明明只需要自行车，但必须装上发动机，得环保电动的……也得能烧油的 于是有了敏捷…… 老发版常在河边走哪能不湿鞋，减少出生产问题啊，前后分离，各司其职，专业的事给专业的人做

[我是橘子呀]

引用 2 楼 咸哼酒家 的回复：

让楼主失望了，我不是个妹子，虽然我也想要有个妹子 现在软件的整体发展趋势是为了更好的服务于业务，以前强调瀑布模型，现在需求他妈的老是变，客户都不清楚要啥 光web端不够，还要APP，还要小程序，要响应好刷新快，还得好看酷炫、洋气上档次 明明只需要自行车，但必须装上发动机，得环保电动的……也得能烧油的 于是有了敏捷…… 老发版常在河边走哪能不湿鞋，减少出生产问题啊，前后分离，各司其职，专业的事给专业的人做

说的没毛病

[我是橘子呀]

说下我自己个人想法吧，可能访问量不会达到，但必须要有，做好前提防范，不然到时候真的有大流量过来，根本来不及

[皮卡丘_后盾]

招聘不都是这样么，面试让造飞机大炮，结果进去是个拧螺丝的

[灬潜龙在渊]

很多人做事情不是考虑事情是什么要怎么做，有时候主要考虑，怎么做才能体现自己的价值，怎么说才能透露出自己的本事，这样子往往能看出这些人内心的浮躁

[聪头]

很多项目都是套模式，不是根据实际情况设计的

[waxf523]

引用 4 楼 Orange软件 的回复:

说下我自己个人想法吧，可能访问量不会达到，但必须要有，做好前提防范，不然到时候真的有大流量过来，根本来不及

讲个悲伤的故事
客户需要一个办公系统，找到将需求文档发给了你和另一个外包公司的负责人。
你回复说这个项目大概要半年时间，考虑到大流量、高并发等因素，我们会采用最新的分布式、微服务等技术，保证这个系统适用于任意场景。
客户问要多少钱，你说50w左右；客户说：你当我傻 逼吗？别人只要10w，半个月就可以搞完，你们公司太坑了，以后都不会再找你们了。

[maradona1984]

招聘信息很多都是用来筛选人的
微服务还是得先改变组织架构,然后再改变代码结构,不然适得其反
同理,一个团队人数少,真没啥必要搞微服务,如果有明确的规划,以后团队会壮大另说
微服务是解决团队过大产生的沟通问题的
如果从代码层面讲,是业务逻辑的高内聚,降低耦合度

[崩溃的油条]

噱头， 国内的跟风程度，不说国内吧， 跟风都一样， 框架应该为了业务 而设计， 而且做为直接 决定技术人，一定要要看 业务 跟 技术团队来决定 技术选型， 跟风大厂， 还不够， 维护起来 都是 辞职信递交， 真的累。 拍脑子做事 不看自己的 情况来决定。

[????@Duxingpeng]

我觉得楼主别看他们写神马，直接去问问谈谈到底侧重点是神马

[bcsflilong]

我见过 好多项目 终端用户不超过20个 结果来用的微服

[weixin_45044320]

筛选人而已 不然一大推怎么选 用不用的上另一回事

[披着虎皮 的石头]

哈哈，我也是转到大数据 微服务上来。 先前是CS 桌面软件开发，现在换到java的 前端页面和 后端数据访问，另外加数据库。 这样网页版，就是访问比较快了，服务器随便搞下，就是部署到三个服务器上，响应服务就高很多了。 手机版也是啊，微信服务号，还有app。

[KeepSayingNo]

分布式、微服务不是说为了跟风，是有了这些东西后，我们将原有的系统升级为这种架构就可以做很多其他的事情，比如原来主要聚焦核心业务数据的存储，现在可以存储更多非核心的数据，利用这些数据可以进行例如画像这样的应用的开发

[聪头]

大多还是炒概念。系统建立在业务需求上，有些是不需要的。

[viewgroup]

还是因为跟风啊，不过如果涉及的模块多，并且模块之间耦合性低还是可以用微服务的，毕竟，模块多意味着以后修改多，这样单一模块修改就不用动其他模块了， 像一些模块少的应用，还不如用MVC呢，方便，快捷

[XGrscM]

老板：公司可以不用，你不能不会。俗话说，面试造火箭，工作拧螺丝，哪家老板不希望自家手下干活的懂得越多越好呢

[比特灵]

一般在好的预期下，要做好以后的扩展准备，防止业务量发生变化、业务情况发生变化时无法处理，而且这种分布式、微服务等等随着时间的推移，越来越容易实现。

[nayi_224]

就像你说的一样，这些技术对很多项目来说都是扯。 楼上也有说优点的，说的没错，但是不少都有更简单直接的办法。 但是这些技术真正的优点你已经经历过了，你们甲方要求你用这些，正好就说明套用这些技术的项目更容易抢到合同。 很多时候，老板不懂，甲方也不懂，用户更不懂，又或者有些人在装不懂，这种时候技术是否适用实际已经不重要了。这只是公司抢合同、个人提工资的一个筹码而已。

[飞向海洋的猪]

感觉微服务就是为了区分模块，那个模块要变动，就改那个模块，同时也避免了系统的臃肿。可以理解为拔插式模块，坏了，拔下修修，不要了，拔下来扔了