腾飞答"不忘初心"的三个问题

最新推荐文章于 2022-10-13 16:14:42 发布

dotNET跨平台

最新推荐文章于 2022-10-13 16:14:42 发布

阅读量331

点赞数

去年的时候有同学在微信上问了我3个问题，我觉得非常有代表性，当时没有回答。主要是通过简短的语言无法全面表述可能会产生歧义，所以决定专门写一篇文章来表达一下我的想法，需要说明的是以下内容只是以我个人的经验给大家一些参考。

初心同学的第一个问题：

我现在有两三个问题，第一个，您觉着NetCore会火起来吗，或者说会比现在好吗，现在政府部门各种国产化是事实。好像确实比较认java，毕竟政府部门，有一定的风向标作用

这是第一个问题，但它并不是一个问题，实际上它包括了如下问题：

.NetCore会火起来吗？或者说会比现在更好吗？
政府部门认Java吗, 在国内算是计算机语言的风向标吗？

初心同学的第二个问题：

嗯嗯，第二个，您是怎么看今年各大互联网裁员的事情，程序员年纪大了，注定被裁员吗，您觉着裁员潮会波及范围很大吗，二线目前没看出影响，之前我在北京来着，回石家庄一年了

互联网公司裁员是怎么回事？
二线城市的程序员发展与生存问题？

初心同学的第三个问题：

最后这个，我描述不清楚。您觉着怎么才算一个优秀的coder。因为很多程序，3年左右的程序员，慢慢写，只要用心，也能写的差不多。5年左右的可能代码写的更好些，效率更高点，也可能两者都写出要求的最优代码。

怎样才算一个优秀的coder?
职业规划的问题

列出来之后一看，这位同学是想框我，这明明是6个问题呀。好吧，我们第一个开始说起。

.Net Core会火起来吗？

当然，肯定。一定会越来越好。

为什么如此肯定？第一主要是因为已经不能再坏到哪里去了，过去十年是互联网和移动互联网的黄金十年，C#没有被当作主要语言被广泛使用。在诸多原因的影响下原来那些使用C#语言作为主要开发语言的一线互联网公司也逐渐开始将新的项目切换成使用Java来开发。而移动互联网的浪潮也已经见顶，到了这个时候，可以说该转的和该换的也都换了。

如果说不能更坏了，那它为什么会变好呢? 因为它值。我想我在这里就不用数据和实例来举证了，网络上有很多再者这本来就是一篇主观的文章。ASP.NET Core弥补了之前不能跨平台的不足，同时又完全开源，再加上性能高和语法简洁优雅、模块化设设计等诸多特性。从.net core3.1版本来看将grpc提到一等公民的位置上可见.net core布局高远，并且脚踏实地地走在了前面。我们完全可以相信asp.net core会是最好的web框架之一。

更何况还有服务网格的加持。服务网格是什么？如果你开发一个单体的应用，ASP.NET Core做为Web框架来做API的实现，如果你开发的是一个大型分布式应用，那么后端除了服务的开发你必然会考虑这些事情：

服务之前如何通信（HTTP？，同步还是异步）
服务注册与发现
服务追踪
服务通信容错（重试/超时/熔断/限流）
...

当然一个大型分布式应用肯定不止仅仅考虑上面的问题，但是这些是最基础的问题。对应SpringCloud全家桶他们有拿来就用的方案。

我们真的需要这样的微服务框架吗？那些主流的微服务框架，不管是类库性质的Finagle、Hystrix，还是框架性质的Spring Cloud、Dubbo，本质上都归于应用内解决方案，都存在以下三个问题：

技术门槛高：

随着微服务实施水平的不断深化，除了基础的服务发现、配置中心和授权管理之外，团队将不可避免的在服务治理层面面临各类新的挑战，包括但不限于分布式跟踪、熔断降级、灰度发布、故障切换等，这对团队提出了非常高的技术要求。

多语言支持不足：

对于稍具规模的团队，尤其在高速成长的互联网创业公司，多语言的技术栈是常态，跨语言的服务调用也是常态，但目前开源社区上并没有一套统一的、跨语言的微服务技术栈。

代码侵入性强：

主流的微服务框架（比如Spring Cloud、Dubbo）或多或少都对业务代码有一定的侵入性，框架替换成本高，导致业务团队配合意愿低，微服务落地困难。

这些问题加起来导致的结果就是，在实施微服务的过程中，小团队Hold不住，大公司推不动。针对微服务有3个版本的说法：

微服务 1.0，仅使用注册发现，基于 SpringCloud 或者 Dubbo 进行开发，目前意图实施微服务的传统企业大部分处于这个阶段，或者正从单体应用，向这个阶段过渡，处于 0.5 的阶段；

微服务 2.0，使用了熔断，限流，降级等服务治理策略，并配备完整微服务工具和平台，目前大部分互联网企业处于这个阶段。传统企业中的领头羊，在做互联网转型的过程中，正在向这个阶段过渡，处于 1.5 的阶段；

微服务 3.0，Service Mesh 将服务治理作为通用组件，下沉到平台层实现，使得应用层仅仅关注业务逻辑，平台层可以根据业务监控自动调度和参数调整，实现 AIOps 和智能调度。目前一线互联网公司在进行这方面的尝试。

从0.5到2.0是一个痛苦的过程，现在所有的大型互联网公司包括BAT和TMD基本都走过，也只有他们的体量才可以支撑这样的人力、财力在期望的时间内完成。对于其它的中小企业来说，可能会因为技术调整而错失最佳的发展时机。

而好消息是，由于服务网格中基础设施层抽象的特性，从0.5到3.0可以跳过 1.0和2.0。享受BAT级别的基础设施以及提供7*24小时的高可用服务不再像以前那样难。

服务网格作为 sidecar 运行，对应用程序来说是透明，所有应用程序间的流量都会通过它，所以对应用程序流量的控制都可以在 service mesh 中实现。

eShopOnContainers是ASP.NET Core官方团队做了一个基于微服务架构的示例项目，现在最新版本已经加入了grpc和服务网格(Service Mesh)的支持。

也许ASP.NET Core目前没有这样可以拿来就用的全家桶，但是随着服务网格趋于成熟，ASP.NET Core在大型分布式服务的技术选型上“生态不足”这一短板可以被划掉了。

虽然ASP.NET Core会是更好的web框架，但是它没有可能去挑战Java的地位。存量只会稳定地延续，而增量来自于5G、AR以及AI这些新兴市场，也可以说是下一个大的浪潮。它们会以怎样的形式到来，我们会不会参与其中，没有人知道。也取决于.NETer开发者本身这个群体有多少优秀的领导者能够在未来的市场中做出一些成绩。我们也许可以把眼界放的更开阔一些，多了解一些，借着过去吃过的亏在将来赢一些胜算。