2019 中国.NET 开发者峰会目前在国内的.NET社区还是很有影响力的,宣传的内容也都是比较新潮和前言的技术栈。
有一个不争的现实是基本上主题都是关于.NET Core的,以及基于该主题之上的延展。比如ML.NET相关的机器学习;基于.NET Core的微服务实战;传统转型.NET Core的实战;.NET Core在物联网的应用;.NET Core结合K8S的应用;.NET Core架构历史;.NET Core相关的云原生技术等等。可谓欣欣向荣,百花齐放,仿佛让人看到了.NET生态的重新崛起。
峰会的内容给开发者开启了一个明亮的窗口,但毕竟只是抛砖迎玉,真正落地开花还有很长的距离。
本人在.NET Core上面落地过,对微服务也兴味黯然,所以我重点倾听了刘腾飞老师的演讲,并做部分解读,从共鸣中写下个人感想,希望对您有所启发。
为什么选择微服务?虽然刘老师的说辞有点举重若轻,说的是因为执着和技术人的专研精神选择了微服务,甚至也对比和调研过,但是在只有四个人的团队里,连一张披萨都没有凑齐的前提下就“冒然”选型,显然不能让我信服。可能是刘大佬有比较充分的调研和把握,或者说有一定的技术自信。否则换成我,我是无论如何不敢带着四个缺少微服务实战经验的小伙伴贸然前进,除非我想把这个项目当成试验品。
因为如果分层架构足够规范简单,团队规范足够精细,设计面向微服务的架构就足够解决问题,等团队和业务发展壮大后,再切换到微服务不迟。
刘佬团队中间加过多少班,踩过多少坑,也许只有刘老师知道。
演讲中插曲说:有一次加班到凌晨3点多,然后一起出来吃火锅。我听完除了敬佩还是敬佩。有句话叫哪里有岁月静好,因为有人替你负载前行。
微服务难在哪里?因为微服务确实需要比较高的门槛,具体可以参考我的另外一篇文章《漫谈何时从单体架构迁移到微服务?》
微服务的基础设施包括:
CI、CD,限流,熔断,管理协作,分布式技术,
网关,服务监控,日志收集,重复代码
配置中心,负载均衡,发布成本
领域划分和明确
容器相关技术栈等等
也就是说对于服务来说,单个服务变得简单,整体服务变得复杂。
这些菜都端上来,如果没有很好的技术储备和高效管理和协作,估计是要不消化的。重点是刘大佬在演讲最后,仍然没有给提问者一个很好的关于分布式事务的解决方案。
如何降低微服务的成本?这里的目的是探讨如何降低成本,所以我们必须要面对这些困难,一个一个的去解决。当这些困难的成本和单体一致或持续的接近单体的时候,我觉得上微服务就胸有成竹了。
为此我们必须要梳理并识别以上的技术难点,这里挑选最核心的或者说最影响时间成本的点来展开。
引入K8S面对JAVA的SPRING全家桶,刘佬采用K8S来解决,也就是说K8S自带微服务等大部分基础设施,比如配置中心不一定要用Appolo,使用K8S的ConfigMap就可以了;服务发现和注册也是K8S自带的。K8S解决了基础设施一半以上的问题,这个成本是非常低的。
也就是说对微服务的学习成本,变成了对K8S的学习成本。这对开发人员来说是个福音,因为可以有现成的轮子,但是也不能高兴太早,因为K8S并不是一个容易掌握的技术。可以说K8S内容庞杂,官方文档也是大而全,想要一下子掌握它非一日之寒。
剩下的另外一半成本在哪儿?我觉得服务划分,服务调用,相关提效工具的使用等等。
服务划分前期服务的划分,包括基础服务,核心服务,网关选型,全链路监控等技术栈。包括但不限于如下表所示:
服务调用:
服务在相互调用的时候,难免会产生重复模型,比如DTO。
使用HTTP请求的性能不足问题
采用gRPC
采用gRPC后服务开发解决单体开发,减少冗余的代码,做到分布式部署和本地部署。
分布式跨服务访问,读写操作做分离,尽量只做查询,POST操作走异步消息事件。