做汽配的 哪一个网站比较好,宁波育才建设教育集团网站,文创产品设计展板,wordpress 论坛主题2019 中国.NET 开发者峰会目前在国内的.NET社区还是很有影响力的#xff0c;宣传的内容也都是比较新潮和前言的技术栈。有一个不争的现实是基本上主题都是关于.NET Core的#xff0c;以及基于该主题之上的延展。比如ML.NET相关的机器学习#xff1b;基于.NET Core的微服务实… 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前后端分离往往会降低我们的开发效率因为互相等待是常有的事情就算模拟好数据后也不能保证不去做联调。终极价值 刘佬说“微服务的终极价值在于服务的任意拼装组合。“ 好比乐高积木比起单体粗苯的代码调整显然是高效率解放生产力的。这种价值其实并不新鲜从历史的维度看从最小的函数封装抽象设计模式类库到进程交互到最后亚马逊的微服务发明无不在学习乐高思想。只是随着业务复杂度的增加团队规模的膨胀这个乐高的粒度不断的变大变远最后跨进程跨域分布式。提问和启发 在演讲结束的提问环节问了三个问题我觉得很有质量也是难点。如何保持数据一致性 刘佬的项目在数据一致性这块没有落地具体原因没说明但是我预估当初是业务优先所做的妥协。 分布式事务具备一定的复杂性是个很大的话题。分布式事务一般采用的是最终一致性也就是CAP里面的三选二通过牺牲实时来保证业务的高可用性。电商中如果不涉及到资金安全比如虚拟钱包和货币等核心业务功能一般不影响使用。 而这里的最终一致性要落地好技术上虽然不难但是要落地完整需要不少时间。如何解决K8S服务干扰 某个服务因为各种原因比如代码不够健壮导致或者因为ES的大内存需求导致集群其他服务异常甚至整个集群垮掉该如何解决容器资源限制核心服务抽离 主要采用资源限制但是资源限制会导致某个容器挂掉。可以通过资源告警和日志分析的方式快速定位容器并进行资源重新伸缩分配特别是在生产环境。如何解决数据库运维 随着数据库和服务一起拆分数据库也变多了给数据库运维带来了极大挑战。 拆分的痛点是表关联查询因为所有的聚合都是服务的聚合也就是数据库的Join没有了替换成的是服务间的关联了所以刘佬干脆弃用MySQL全部采用MongoDB充分发挥MongoDB优势。 但是接下来的代价就是统计和报表的生成这个难题也不复杂可以通过数据同步把MongoDB的数据同步到关系型数据库当中。 对于业务统计或用户行为事件会产生很大的数据量可以在服务入口处做探针比如在用户访问下订单服务处埋点把访问和统计数据同步到ES发挥ES的威力最后通过Dashboard来进行显示
