搞软件架构,是不是绕不开 Java ?
单机和 App 架构就不说了,没什么深度。
多机、多服务、多并发这类系统,不会 java 都不好意思称自己是架构师吧?
Java 何以长成这样的大树
现在开源大行其道,很多公司说白了就是在拼拼凑凑,稳定现成可用的越多,成本越低,自然普及。
啊,主 golang 的字节已经这么没有牌面了吗
架构师的工作中有一项叫做技术选型,需要架构师具备广泛的知识储备,以及可靠的技术雷达,当遇到一项需求的时候,能够合理分析,选择适合需求的技术来实现。
所以当今只要是上了一定规模的系统,都是由多种技术栈组合而成的,举个例子:某企业业务逻辑部分用 Java,高性能组件用 C++,微服务是 Go,API 网关是 Node.js ,大数据分析是 Scala 和 Python 。物尽其用。
技术都是工具,虽然每个工具的功能都比较丰富,但是工具总是有其擅长的领域,所以得从实际需求出发,合理选择技术。
除了需求本身的特性以外,架构师还要考虑现有的技术包袱、人员的能力、管理成本以及未来的规划,比如如果团队里综合最熟练的只有 Java,而且用 Java 也不会带来高成本或高风险问题,那也是可以考虑整体全用 Java 的。
架构其实就是解决问题的思路,比如说 MVC,并不是特指的只能用 Java 来实现的架构,而是一种通过将系统抽象成 Model 、View 、Controller 三层来实现一种动态的程序设计,使后续对程序的修改和扩展简化。需要说明的是,MVC 是 1978 年提出的,而 Java 是 1995 年发行的。
所以可以说 Java 以其悠长的历史、广大的社区、丰富的案例储备,能让人了解到和学习各种架构。但是也并不是说离了 Java 就没法谈架构了,你看,前端工程师近几年也在架构上玩得 66 的(阿里云已经实现前端微服务架构了,用于解决云控制台大量模块和技术栈混合的问题)。
> 离开 Java 的世界,基本上离开了做架构的世界(相关解释见文末)
> 注:我以为用 Java 适合做架构这事应该是常识了,但是评论中有很多人非常反对这个事。那我解释一下吧:首先,小型的项目用什么语言都行,爱用什么用什么。但是,真正的企业级架构就不一样了,其中并不仅仅只是 RESTful API 或 RPC,还有各种配套设施和控制系统,比如:应用网关,服务发现、配置中心、健康检查、服务监控、服务治理(熔断、限流、幂等、重试、隔离、事务补偿)、Tracing 监控、SOA/ESB 、CQRS 、EDA……这些东西在非 Java 的技术栈体系内,很难看到全貌,Java 强大的生态环境,就是让你把注意力放到更高层次的架构和业务上来的。(千万不要觉得,整几个服务 RPC 一下,加个缓存,加个队列,就能叫架构,那只是系统集成罢了)
至于业务算大算小我不在乎,我只在乎业务是否转的好(无论负载多少),我不在乎使用什么语言(但我会综合优缺点进行选择),百万连接我已经说了,说大不大说小不小,你觉得小就往小的方向理解即可,毕竟再大的项目归根揭底还是很简单的 crud 。
再大的项目都有个共同点:不去挑战单机极限,都在回避单点瓶颈。
很多公司并不像那家电商公司一样全都是 Java 的。比如企鹅,比如飞期布克。
架构是 App 与 App,Service 与 Service 之间的组成方式。