微服务的时间和成本去哪儿了

最新推荐文章于 2022-09-06 19:46:59 发布

张飞洪

最新推荐文章于 2022-09-06 19:46:59 发布

阅读量23

点赞数

文章标签：微服务架构云原生

本文链接：https://blog.csdn.net/u011301518/article/details/140020183

版权

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操作走异步消息事件。

　　刘佬提到的服务调用连续迭代了三个版本，这个坑给我很大启发，虽然我目前的服务没有采用gRPC，但是模型的代码重复已经开始冗余了。代码冗余不可避免，有没有更好的解决方案呢？有些人会觉得引入Abp框架来解决，最新的Abp Next。这是很好的轮子，但是问题又来了，Abp Next和K8S一样，如果团队没有好的研发型人员或者对Abp的使用有过几个项目垫底的人，那么Abp的引入可能会增加技术的复杂度，因为Abp在性能方面也是有坑的，何况Abp Next目前也在跟着迭代，文档都不是很健全。

工具使用

　　工具是微服务基础设施的一部分，比如基于gitLab的CI,CD或者jenkins。都是服务自动化发布的利器。另外API接口膨胀后的管理，联调，测试，规范等等，如果没有管好API，前后端分离往往会降低我们的开发效率，因为互相等待是常有的事情，就算模拟好数据后，也不能保证不去做联调。

终极价值

　　刘佬说：“微服务的终极价值在于服务的任意拼装组合。“

　　好比乐高积木，比起单体粗苯的代码调整，显然是高效率解放生产力的。这种价值其实并不新鲜，从历史的维度看，从最小的函数封装，抽象，设计模式，类库，到进程交互，到最后亚马逊的微服务发明，无不在学习乐高思想。只是随着业务复杂度的增加，团队规模的膨胀，这个乐高的粒度不断的变大，变远，最后跨进程，跨域，分布式。