微服务时代之2017年五军之战:Net PHP谁先死
其实我一直是个懒人,开博也有好几年了,但是一直懒得写文章,主要怕打字麻烦, 手机都是用讯飞语音输入的, 可惜博客里面很多专业性的词语,用讯飞也不大好,另外无论在家还是在公司,开个语音一本正经的叽叽叽,画面也太美好,干脆还是手打吧,对观众也是一个尊重
这个话题实在不想开,主要是怕开了,各路大军蜂拥而至,一人一口唾液也被喷死了,原来只要一讨论.net java php谁好,马上就有混战了,最终以PHP是世界上最好的语言为结论休战,讲真,作为一个IT界混了这么多年的人,啥语言都要会点,要不然你真不好意思出来围观,所以在MVC之前的时期,根本也无所谓那种语言好,哪种不好,都是半斤八两吧。 不过在那个时期,很公正的讲:
1 .Net 还不错,尤其是VS开发环境,那调试真心爽,代码也很优雅,唯一不足就是.net 环境很恶心,各种体积大,各种向后兼容,搞的实施人员骂娘
2 JAVA也不错,这几年一直是我的主开发语言,主要是一个JDK跑天下,各种平台爽呆呆。当然各种Jar包也会找的你哭,直到Maven这个神器出来一统江湖,大家都爽了,唯一偶尔还骂一下的也就Eclipse了。当然也有用其他IDE的,在此不多评论,用过VS的话都得趴下。
3 PHP嘛,我不知道怎么讲了,好像连喷的引子都没有了, 比IDE? PHP有IDE么? 比调试? PHP 有调试么? 比中间件?PHP有中间件么? 当然,PHP开发还是蛮快的,有他自身的优点(一大波PHPer正在赶来,好吧,PHP是世界上最好的语言)
4 GO&NodeJS Python 二线语言, 各位大爷先别喷, 真正的大型,大规模产品,还真没用这几个语言开发的,有个别用的后果也是最终转上面3个大哥
5 其他语言 IOS ,C++ 等, 不说了,没法喷,地球的未来是互联网时代。除了图形及前端运算等需要,这类语言不会消失,但生存空间会越来越小。现在铺天盖地的混合开发框架已经在不停的打压前端语言了。
好了, 五军凑齐,但是真正开战的主力,还是前3个, 后面2个的粉丝可以先去讨论下PHP是不是世界上最好的语言,然后再过来观战
为什么前三个要开战呢? 主要还是从16年下半年开始,蓬勃发展的微服务架构,Docker DevOPS ,这两个家伙把IT市场彻底给搅乱了,不明真相的吃瓜群众肯定说:用自己的开发语言就好,其他管我屁事? 且听我继续道来,这2个家伙终究要改变世界,啊不,终究要改变IT界的生存模式。
1. 首先受到冲击的就是运维人员, 这群庞大的组织,因为Docker DevOps的存在,会逐渐消亡,因为以后基本不需要什么实施,也不需要蹲点运维了,所有的功能代码,最终交付形态都是一个image镜像,一个DevOps人员就可以完成自动化构建,生成Docker镜像,集群化部署。 而传统的安装文档Step1-Step100就再也没人看了。
这块影响最大的,可能就是依赖于IBM,Oracle等巨头中间件的这部分人了,想当年,IBM靠WebSphere中间件系列, Tovoli系列养活了多少实施运维人员,工资傻高,福利贼好,但是Docker一出谁与争锋,DevOps概念深入身心,开发运维一体化将是未来唯一主流的道路
2. 其次受到冲击的,就是传统思维,传统架构的的开发人员,16年下半年开始,JAVA率先转入微服务仙域,坐看人间百态,笑而不语。因为SpringBoot和SpringCloud完美支持无缝对接微服务,那可是JAVA的亲大爷,.Net只有干瞪眼的份,无奈天生基因形态,无法有效实现微服务,更别说像SpringCloud的生态链了,不过微软打死都不改变,你Linux有Docker,我也得弄个Docker,好嘛,出来的是基于微软Hyper-V的,微软引以为豪的界面型操作,在Docker命令型操作面前被轰成了渣渣,没办法,把PowerShell改下,全学Linux的Shell,奈何最终是一个四不像,搞得人都不愿意用,干嘛费那么大劲学PowerShell?直接转Linux多开心? .Net Core 也开始跨平台,可惜背后的生态链都无法完美进入Docker,更别说DevOps的思路了。所以.Net Core看起来很美好,其实道路还是很曲折的,一个人对抗整个JAVA生态链,还是太弱。至于PHP,怎么升仙进入微服务? 请先把自己的MVC搞定再来发言吧。 什么?有同学说PHP的MVC有啊,好吧,请先去参观研究下JAVA 和.Net的MVC吧。
3. 另外一个受影响的,应该是互联网甚至是整个IT界的运作模式了,目前虽然收到冲击,但是还不算致命,但是未来1-3年内,肯定要大变样,主流应用,主流互联网产品可能都会转型到微服务模式,毕竟从快速开发实现,快速迭代,及时响应变更,同时降低成本方面考虑,企业都愿意接受更好的方案。传统企业,国企政企嘛,想想就算了,真带不动,一群只会用XP IE6的群体,和互联网本身就是互斥的,所以对于在这类产品环境下生存的ITer们,就要考虑了,不转微服务,那你的技术生涯可能也就2-3年了,转微服务?那估计只能跳槽了。毕竟对于思想排斥互联网,动不动就是管控,内网,各种约束,是无法有效高效利用互联网带来的价值的。
好了,说了这么多,也简单说下微服务+Docker+DevOps的简要流程和关键点:
传统模式: 1.开发代码-》2.测试-》3.打生产包,写部署文档,数据库脚本,其他环境要求-》4.实施人员安装-》5.运维人员维护,备份数据-》6.再次循环1-5过程
这期间基本每个环节到下一步都会出现扯皮的情况,就是各种不行,各种验证,各种开骂。环节多了,经手人就多,出问题几率就大
DevOps模式: 1.开发代码-》2.测试-》3.提交Git/SVN 自动构建生成Docker镜像-》4.,自动发布集群 -》5循环3-4过程
这种模式,只关注2个重要点,第一个是代码,第二个是生产环境的共享存储,尤其是在云计算环境下,就更爽,其他的服务器,环节操作,都可以随时销毁,随时重建。
这里面需要重点强调下Docker的牛逼之处, 传统模式,如果需要建立分布式集群,那是需要几个软硬件专家,或利用各种中间件来实现,维护难度,企业成本不是一般的高,买软件,加服务器,甚至实施运维都是皇帝,公司惹不起,没事给你来个删库毁集群再跑路,哭都来不及。而Docker出现后,就把这部分群体彻底废掉了,随时随地加服务器,硬的,虚拟的,云的,统统只要一行命令就搞定。随便删,随便Down,随便加,有了Docker都不怕。
讲了这么多,吃瓜群众不乐意了,不是五军之战么? 到底还打不打了? 不打退票~!
好,前面也说了,主站还是3军 JAVA .Net PhP , 其实JAVA是不战而胜, 所有的微服务Docker几乎是为JAVA 量身定做的。剩下就看.Net 和PHP的生态链如何来PK了
从15年底,微软开始亲近开源社区来看,后续一系列动作,包括.Net Core 1.0发行,到现在2.0. 基本跨平台还算可以, 尤其引入Nuget生态系统,可以说弥补了.net的很多不足
整体生态链已经在建设,我认为可以达到JAVA的30%-35% ,而自动化构建本身也是.Net的强项,可以达到95%,唯一不足的是这个生态圈子以Win为主,无法跨平台,Docker部分
我觉得微软路子没选对, 可能考虑到自家的生态系统,所以选择了以Hyper-V作为Docker的核心,导致Linux中众多的Docker服务,无法在Win下使用,其实微软既然在新Win里面嵌入了MiniLinux,完全可以以此为基础,进行加强,形成一个混合的系统,连Docker也可以混合支持Linux。但是现在微软在Docker的做法,可能真的就把Win系统生态链带入绝境。 开始我也说了,未来是Docker的世界,这块不做好,只有死路一条。
至于PHP,我已经找不到好的切入点了,因为基本的MVC,就和JAVA .Net相差一部分,而微服务的基本思想,也都会依托与MVC服务,所以这部分至关重要,成熟的MVC框架,包括其身后的生态系统支撑,才能形成可靠的微服务系统。 当然Docker的话PHP也是可以很快集成融入。 唯一不足的可能就在于微服务的基本基因较弱吧。至于服务发现,服务熔断降级,全局配置中心,统一网关,PHP貌似还没有太成熟可靠的生态系统。
基于16年17年的现状来看, .Net已经在改变,但是没有下狠心, PHP可能还在梦游,没有一个统一的组织来引导这个。所以这样持续下去的话,1-3年内PHP先死,2-4年内.Net也仅仅是苟活着了。而市场80%可能都会转入JAVA生态系统了。
微服务时代之2017年五军之战:Net PHP谁先死的更多相关文章
- go微服务框架kratos学习笔记五(kratos 配置中心 paladin config sdk [断剑重铸之日,骑士归来之时])
目录 go微服务框架kratos学习笔记五(kratos 配置中心 paladin config sdk [断剑重铸之日,骑士归来之时]) 静态配置 flag注入 在线热加载配置 远程配置中心 go微 ...
- 通过Dapr实现一个简单的基于.net的微服务电商系统(十五)——集中式接口文档实现
之前有小伙伴在评论区留言说如何集成swagger,最开始没有想透给了对方一个似是而非的回答.实际上后来下来想了一下,用.NET5 提供的Source Generator其实可以很方便的实现接口集成.今 ...
- 微服务时代TestOps工程师学习总结
TestOps很新鲜,也是近期衍生的新型职位.那TestOps主要目的是推动整个研发体系与发布体系更多在质量方面.可以这样理解DevOps是从研发推动配合运维和测试,而TestOps是从测试角度推动研 ...
- 从面向服务架构(SOA)学习:微服务时代应该借鉴的5条经验教训
[编者按]本文作者为 Matt McLarty,通过介绍 SOA 的兴衰变化,总结了微服务应该借鉴的5条经验教训.文章系国内 ITOM 管理平台 OneAPM 编译呈现. SOA 的兴衰变化让我们更了 ...
- 微服务时代之网关相关技术选型及部署(nacos+gateway)
1.场景描述 因要用到微服务,关于注册中心这块,与同事在技术原型上做了讨论,初步定的方案是使用:阿里巴巴的nacos+springcloud gateway,下面表格是同事整理的注册中心对比,以前用的 ...
- 微服务时代之自定义archetype(模板/骨架/脚手架)
1. 场景描述 (1)随着微服务越来越常见,一个大的项目会被拆分成多个小的微服务,jar包以及jar之间的版本冲突问题,变得越来越常见,如何保持整体微服务群jar及版本统一,也变成更加重要了,mave ...
- 【一起学源码-微服务】Ribbon源码五:Ribbon源码解读汇总篇~
前言 想说的话 [一起学源码-微服务-Ribbon]专栏到这里就已经全部结束了,共更新四篇文章. Ribbon比较小巧,这里是直接 读的spring cloud 内嵌封装的版本,里面的各种config ...
- spring cloud微服务快速教程之(五) ZUUL API网关中心
0-前言 我们一个个微服务构建好了,外部的应用如何来访问内部各种各样的微服务呢?在微服务架构中,后端服务往往不直接开放给调用端,而是通过一个API网关根据请求的url,路由到相应的服务.当添加API网 ...
- .Net Core微服务入门全纪录(五)——Ocelot-API网关(下)
前言 上一篇[.Net Core微服务入门全纪录(四)--Ocelot-API网关(上)]已经完成了Ocelot网关的基本搭建,实现了服务入口的统一.当然,这只是API网关的一个最基本功能,它的进阶功 ...
随机推荐
- voa 2015 / 4 / 25
When English speakers talk about time and place, there are three little words that often come up: in ...
- mybatis代理类Demo
前言 简单实现通过代理接口来实现对数据的查询demo,也是对mybatis的一个熟练.首先是编写接口代理. public interface IBookMapper { List<BookMod ...
- Unity Shader入门教程(一)
参考文献:http://www.360doc.com/content/13/0923/15/12282510_316492286.shtml Unity Shader是着色器,将纹理.网格信息输入,得 ...
- 简单的.NET后台定时服务框架
后台服务只要是有一定经验的开发人员都接触过,其中离不开服务创建,调度逻辑处理,业务逻辑编写等环节.往往我们在新建一个后台服务项目的时候都会去拷贝以前的代码,再写一些线程等方式去完成,然后又去处理服务的 ...
- java基础系列--集合类库(一)
原创作品,可以转载,但是请标注出处地址:http://www.cnblogs.com/V1haoge/p/7229478.html 1.概述 Java的集合类库很是丰富,囊括了大部分的常见数据结构形式 ...
- Spring源码情操陶冶-AbstractApplicationContext#prepareRefresh
前言-阅读源码有利于陶冶情操,本文承接前文Spring源码情操陶冶-AbstractApplicationContext 约束: 本文指定contextClass为默认的XmlWebApplicati ...
- 用runtime封装归档(encoding)
runtime一套比较基层的c语言的API(库) 归档(OC对象-->字典—>2进制—>写入沙盒 || 目的.数据持久化) #import <UIKit/UIKit.h&g ...
- Object-C 里面的animation动画效果,核心动画
#import "CoreAnimationViewController.h" @interface CoreAnimationViewController ()@property ...
- 香港服务器PING知识知多少?
香港服务器PING命令简介: PING命令是用来检查要到达的目标IP地址并记录结果,显示目标是否响应以及接收答复所需的时间.如果在传递到目标过程中有错误,ping 命令将显示错误消息. 我们在HOST ...
- RabbitMQ入门-消息派发那些事儿
在上篇<RabbitMQ-高效的Work模式>中,我们了解了Work模型,该模型包括一个生产者,一个消息队列和多个消费者. 我们已经通过实例看出消息队列中的消息是如何被一个或者多个消费者消 ...