最主要是怕需求变更，

职业分母

@fuyufjh #43

你说的这些领域能容纳多少人就业呢？
有多少公司需要这种架构呢？

所有的技术都是为业务服务的
另外业务逻辑是构建大部分应用软件的本质复杂性，
实现工具 技术架构都是次要复杂性，

如果一个软件业务足够复杂，却没有这些非功能性的技术性能需求，
你的这些技术名称又有何种作用呢？

我可以举出上百种场景，其业务逻辑复杂程度到你一个脑子根本就装不下的系统，
其并发数可能一个手就能数出来，

工程软件项目从来都是从 知识领域 问题规模 系统复杂度 出发而来的，
不是上来就扯了一大堆时髦的技术名词

上面说了这么多有什么用呢？
不管是现在还是未来，大的方向 99%软件开发工程师解决的
都是最后一公里的业务需求接入的问题，
即如何将现实的需求转换成计算机可执行的软件实体，
这是现实分工所需要，不以人的主观意志而转移

操作系统发展了这么多年，各种取舍 平衡已经非常成熟了，
编译器语言相关的更是成熟的不能再成熟了，
在软件系统这个领域，各种基础设施早就过了那个群雄争霸的时代了，
另外计算机底层相关领域能够容纳的人是有限的，毕竟市场就那么点大

新兴的 ML 大数据 其实跟计算机的关系已经很小了，核心知识域都是数学相关，
硬要能扯上关系就是伴随 ML 大数据而来的分布式系统，不过这一块也差不多慢慢成熟起来了

未来我觉得技术架构会慢慢趋于统一，或者是编程语言跟框架的发展，会让你慢慢感觉不到架构的存在。

这并不是痴人说梦，早期的计算机语言 要了解很多平台细节，
内存还要手动回收，而今天使用很多高级语言 都已经完全将这些细节忘记
云服务厂商提供高可用的 MySQL 抽象层，让你根本感觉不到 MySQL 方言抽象下面发生的所有事情
未来随着芯片计算速度进一步加快，GC 语言完全淘汰手动管理内存的语言更不是一件难事。

上云了，就直接买 阿里的服务吧，别整那些乱七八糟的，你想要的基本上云都有，何必自己折腾？

死锁的四个必要条件

分母+1

@hubahuba #10
我转行 干了 差不多两年了，真心没觉得 技术上有多难，
算法 如果是略过数学证明，停留在应用上，基本上没什么难度。
计算机相关的基础知识，更是没什么难度，你对高层次的概念有一定理解过后，
再去理解底层的东西，是顺其自然的事情，，像我们经常做 web 后端的，

写 sql 就会出现一种 先读数据，判断数据库的数据是否满足当前写入的状态，然后再进行写入的操作。
有可能你再某篇文章上告诉你，这样在并发较高的情况下不行，
你要去了解 数据库的锁机制 还要隔离机制，你自然而然就会去学
学完了之后 也就有自己的认识了，见识多了，解决问题的能力跟思路就上去了。

@hubahuba #9
菜鸡一枚，只是觉得 搬砖不过就这么回事，真的只要下过苦功夫，找份工作 还是很轻松的。
科班的人 喜欢搞技术，动不动就是 CSAPP 算法就来了，这个其实不适合新手，新手需要的是
尽快熟悉手头的开发工具，在最短的时间内学会技能并给公司创造价值。
在这个行业先活下来，才有发展的机会。

可以编造些实习工作经历，但是打铁还是要自身硬，出来混 早晚是要还的，
我个人从来不搞道德洁癖，道德说穿了是赤裸裸的利益，
你能为公司带来价值 公司才会给你工作机会，至于手段 我觉得每个人有每个人的看法吧。

后端 Java 开发 日常其实主要集中在 几个技能点，

SQL 一定要溜，最好熟悉 MySQL 的方言，别都快找工作了 交集 差集 补集 笛卡尔集 都不清楚

Java 一定要扎实，面向对象 反射 API 堆栈模型 内存模型 垃圾回收模型 都要一一点上去，
不求精通 但一定要有一定的认识，
多线程相关的知识也要点上，别写代码的时候，犯低级错误。

Spring 框架 建议读下 tiny-spring 的源代码 对依赖注入 跟动态代理 有一个完整的认识，代码量其实不大，
这是我 fork 的 https://github.com/jonwinters/tiny-spring 在原本的基础上 添加了一些注释

持久层框架 Mybatis Jpa 都了解一下

最后 GNU 那些工具链 常用的 less vim 可以点一下，方便 测试环境 docker 里面看日志 调试

----
html js 这些天赋就先别点了，一般去了一家公司，让你兼职写点前端，
估计你一下子也照顾不过来，对新人成长其实是不利的，另外这种分工不明的公司
大多都是舍不得花钱请开发人员，去了也没有什么意义。

@Kraken #8

这句话也是有前提的，针对 在业务逻辑并不是特别负责的情况下，
另外所谓高并发 也可以通过 RateLimitter 令牌桶 之类的库来做限流，并不是说一定要上微服务
才能解决高并发问题，另外单体应用也可以部署多个实例 作为备份， 每个实例并没有保存状态，
当单台实例出现问题，，备用实例也可以顶上

如果楼主有疑问，或者不解，可以读一读 人月神话 -> 关于 软件中的固有复杂性与次要复杂性的解释

另外在微服务架构下，软件系统中的很多非固有复杂性，已经在慢慢被解决掉，业内也有非常多的可靠的方案，
像可靠事务消息系统 很多大公司 都有自己一套成熟的技术框架，完全不侵入业务
像熔断 网关 负载均衡 在云服务上 有更多成熟的选择

无论是设计模式，SOLID 原则，所有在代码结构上的 一些编程原则以及各路大师们的总结
最终目的都是追求 关注点分离 这个目标，
因为关注点分离开来 ，能让整个系统更加清晰 ，让开发人员更易于理解 整个系统
让整个系统更易于修改，不会出现 牵一发而动全身的情况

微服务 无关于技术，仅仅是业务架构上的一种诉求。
所有微服务架构能解决的问题，单体应用架构都能解决，而且解决的非常好。

你只有进公司 做过大型项目，跟各种后端团队合作，一堆乱七八糟的业务逻辑跟产品诉求
才能明白微服务的意义，因为造摩天大楼跟造小狗窝 是完全不一样的工作。

开发人员选择使用微服务，最大的好处就是 处理系统边界的问题， 这个系统边界 指的便是代码逻辑的边界，
微服务正是遵从了被所有开放人员奉如圭泉的经典理念 关注点分离原则 -> 分开是为了更好的相聚
被业界吹捧如此

https://ws2.sinaimg.cn/large/005DO33Hgy1frcsw9o726j31eq14idwh.jpg
如果贵司的服务调用是这样.. 我建议还是不要搞微服务了，因为整个系统边界很模糊，职责也分不清楚
当然我们架构师还是很努力的在演化，明确业务跟系统的边界