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

为何选择微服务？

　　虽然刘老师的说辞有点举重若轻，说的是由于执着和技术人的专研精神选择了微服务，甚至也对比和调研过，可是在只有四我的的团队里，连一张披萨都没有凑齐的前提下就“冒然”选型，显然不能让我信服。多是刘大佬有比较充分的调研和把握，或者说有必定的技术自信。不然换成我，我是不管如何不敢带着四个缺乏微服务实战经验的小伙伴贸然前进，除非我想把这个项目当成试验品。

　　由于若是分层架构足够规范简单，团队规范足够精细，设计面向微服务的架构就足够解决问题，等团队和业务发展壮大后，再切换到微服务不迟。

　　刘佬团队中间加过多少班，踩过多少坑，也许只有刘老师知道。

　　演讲中插曲说：有一次加班到凌晨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来进行显示。

> 来源：https://www.cnblogs.com/jackyfei/p/12067708.html

欢迎关注公众号 【码农开花】一块儿学习成长 我会一直分享Java干货，也会分享免费的学习资料课程和面试宝典 回复：【计算机】【设计模式】【面试】有惊喜哦