微服务学习九

　　PPT：https://www.cnblogs.com/MingsonZheng/p/12075597.html

　　2019 中国.NET 开发者峰会目前在国内的.NET社区还是很有影响力的，宣传的内容也都是比较新潮和前言的技术栈。

　　有一个不争的现实是基本上主题都是关于.NET Core的，以及基于该主题之上的延展。比如ML.NET相关的机器学习；基于.NET Core的微服务实战；传统转型.NET Core的实战；.NET Core在物联网的应用；.NET Core结合K8S的应用；.NET Core架构历史；.NET Core相关的云原生技术等等。可谓欣欣向荣，百花齐放，仿佛让人看到了.NET生态的重新崛起。

　　峰会的内容给开发者开启了一个明亮的窗口，但毕竟只是抛砖迎玉，真正落地开花还有很长的距离。

 　　微服务的基础设施包括：

• CI、CD，限流，熔断，管理协作，分布式技术，
• 网关，服务监控，日志收集，重复代码
• 配置中心，负载均衡，发布成本
• 领域划分和明确
• 容器相关技术栈等等

　　也就是说对于服务来说，单个服务变得简单，整体服务变得复杂。

　　分布式事务的解决方案。

 　　数据传输对象（DTO)(Data Transfer Object)，是一种设计模式之间传输数据的软件应用系统

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

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

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

　　
　　如何保持数据一致性？

　　　　刘佬的项目在数据一致性这块没有落地，具体原因没说明，但是我预估当初是业务优先所做的妥协。

　　　　分布式事务具备一定的复杂性，是个很大的话题。分布式事务一般采用的是最终一致性，也就是CAP里面的三选二，通过牺牲实时来保证业务的高可用性。电商中如果不涉及到资金安全，比如虚拟钱包和货币等核心业务功能，一般不影响使用。

　　　　而这里的最终一致性要落地好，技术上虽然不难，但是要落地完整，需要不少时间。

　　如何解决数据库运维？

　　　　随着数据库和服务一起拆分，数据库也变多了，给数据库运维带来了极大挑战。

　　　　拆分的痛点是表关联查询，因为所有的聚合都是服务的聚合，也就是数据库的Join没有了，替换成的是服务间的关联了，所以刘佬干脆弃用MySQL，全部采用MongoDB，充分发挥MongoDB优势。

　　　　但是接下来的代价就是统计和报表的生成，这个难题也不复杂，可以通过数据同步，把MongoDB的数据同步到关系型数据库当中。

　　　　对于业务统计或用户行为事件，会产生很大的数据量，可以在服务入口处做探针，比如在用户访问，下订单服务处埋点，把访问和统计数据同步到ES，发挥ES的威力，最后通过Dashboard来进行显示。

 

　　

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

　　参考：漫谈何时从单体架构迁移到微服务？

　　参考：浅析VO、DTO、DO、PO的概念、区别和用处