2020年，我来盘点下.NET微服务架构技术栈
2020年了，很多⼩伙伴⼉对微服务还⽐较陌⽣，说起来很多⼈可能不敢相信，其实微服务这个概念早在2012年就提出来了，经过了这些年的发展，现在已经成为企业⾮常主流的架构选项了。今天，我就来带⼤家⼀起探讨下微服务的前世今⽣，以及在.Net Core下该如何落地。(⽂章较长下为全⽂⽬录，全⼿写，轻拍！想省⼼也可以扫码看视频版解说)。
本⽂⽬录
贴⼼的我还准备了真⼈视频解说！⽂章太长读不下去？直接扫码上图领取视频，听我讲给你听~ 微服务的前世今⽣
与微服务架构相对的，叫单体架构。这是我们最熟悉的开发⽅式，就是⼀个项⽬搞定业务全过程，在同⼀个进程⾥⾯完成。随着业务发展，数据量和并发上去了，⼀般会选择右边的垂直拆分，拆分后的每个系统，依旧是单体架构的。
垂直拆分后，⼦系统都能独⽴做集，承载能⼒⼤⼤提升。但随着业务进⼀步发展，⼦系统会越来臃肿，⽽且根据⼆⼋原则，80%的请求其实都集中在20%的业务上，不同的⼦系统也都有很多重复的功能模块。于是乎分布式就诞⽣了，将⾼频重复的功能拆成独⽴的服务部署，各系统都通过调⽤服务来完成功能。
分布式拆出服务独⽴部署和维护，既完成了功能的复⽤，⼜能保证⾼频服务的伸缩性和⾼可⽤，代表着更⾼的⽣产⼒。然⽽欲戴王冠必承其重，分布式带来的问题跟提供的价值⼀样多，⽐如分布式锁、⼀致性、可⽤性、复杂度等要命问题。
随着时间推移，业务倒逼技术进步，在⼤数据⾼并发的要求下，分布式技术慢慢开始成熟，针对各种问题都形成了⾏之有效的办法，然后分布式也成了架构设计系统的常规⼿段。基于服务的形式来完成对业务的解耦，提供⾼可⽤和伸缩性的特性，满⾜了⽇益增长的业务需求。随着业务的不断拆分，粒度越来越细，⼀个新的称谓微服务(Microservice)就应运⽽⽣！
什么是微服务架构？我理解为是⼀种架构设计系统的风格，基于⼩粒度的服务来完成对业务的解耦，将业务流程拆分成多个服务组装。就像以前三层架构⾥⾯，⼀个业务会调⽤多个BLL⽅法，⽽现在换成了调⽤多个服务。这就是微服务了，当然，⼩伙伴⼉认真想想会发现，真的要落地微服务，问题太多了！下⾯，我就以.Net Core技术栈下，对微服务架构落地的种种问题和解决⽅案来⼀⼀探讨！落地微服务架构
⼀、进程间通信：这个是构建微服务的基础，通常有以下三⼤类：
1.基于第三⽅存储共享的通讯(数据库/Redis/队列等)
2.基于Http协议的服务(WebService/WCF/WebApi)
3.远程调⽤模式(FX下的RPC和.Net Core下的gRPC)
⼆、服务注册与发现：
微服务架构是搭建在底层服务实例基础上，必须通过集来保证服务的⾼可⽤和动态伸缩，因此服务注册，服务发现，健康检查，异常下线功能都是必须的，在.Net Core下可以考虑选择Consul(⾸选)、etcd或者ZooKeeper。
三、⽹关Gateway
微服务架构⽀持多客户端共⽤服务，⽽且底层服务数⽬众多，不可能全部都暴露给外部客户端(安全隐患/公⽹IP)，⽽且多客户端也不可能维护⽆⽌境的服务实例地址，因此⽹关gateway是必须的！就像门⾯模式Façade⼀样管理好底层服务，通过路由映射底层服务实例，客户端⼀律通过⽹关来完成服务调⽤。此外，由于请求都从⽹关⾛，那么也可以在⽹关这⾥完成鉴权授权、限流、熔断、降级等进阶功能。
四、鉴权授权
以上是系统架构，往下是功能性需求
五、瞬态故障处理
真的去写代码时，你会发现调⽤服务总没有调⽤⽅法那么⽅便，会因为⽹络、延迟等造成种种意外，因此需要⼀种优雅的⽅式来执⾏请求重试、超时处理、故障恢复等策略，⽬前.Net Core下推荐使⽤Polly，常见应⽤是集成到gateway或者AOP的模式插⼊到客户端⾥⾯。
六、分布式追踪
⼀个请求会涉及多个服务，⽽服务本⾝还有依赖，整个请求路径就构成了⼀个⽹状的调⽤链，想象⼀下其实挺害怕！在整个调⽤链中⼀旦某个节点发⽣异常，整个调⽤链的稳定性就会受到影响，因此必须得有跟踪请求，性能分析的⼯具，以便快速定位和解决问题。SkyWalking (推荐)、Cat、Zipkin、Pinpoint都是可选项，这⾥就不建议⼤家⾃⼰造轮⼦了。
七、⽇志收集与分析
微服务下的⽇志已经不是单机系统⽇志那么简单，茫茫多的服务节点，复杂的依赖调⽤关系，会带来海量的⽇志，⼀套优秀的分布式⽇志收集和分析框架是必须⼊⼿的，这⾥我给⼤家推荐的是ExceptionLess，⼊⼿简单资料齐全。
⼋、统⼀配置中⼼
配置管理平台是必不可少的，那么多服务那么多集，⼀个个⼈⾁管理会疯掉的。Apollo能够集中化管
理应⽤不同环境、不同集的配置，配置修改后能够实时推送到应⽤端，并且具备规范的权限、流程治理等特性，是由携程框架部门研发的开源配置管理中⼼，.Net社区的骄傲，点赞！
九、分布式锁
单体架构下，多线程操作同⼀个对象，可以⽤lock锁保证只有⼀个线程能进⼊，微服务架构多进程下，怎么管控？核⼼思路是基于第三⽅的共享数据访问加上互斥逻辑来完成管控，像数据库/Nosql/Consul等介质均可。实践中，Redis是⾸选不解释。
⼗、分布式事务
CAP有⾔，在分布式的情况下，系统的可⽤性和⼀致性是没法同时满⾜的。微服务体系下，⼀个业务请求都需要N个服务节点协作，可⽤性是最⾼优先级，否则系统没法正常运转了。那如何数据的⼀致性怎么办？当下主流的模式有3
种，2PC/3PC，TCC以及本地消息表，前⼀个是牺牲可⽤性去保障⼀致性，⽤的较少，后⾯都是保障数据最终⼀致性。⽬前在互联⽹公司主流选择是下图的基于消息队列的分布式事务实现。
⼗⼀、Jenkins-CI/CD
持续集成持续交付(CI/CD)是敏捷开发的核⼼，在微服务架构下也是常备的。简单来说，就是能持续的合并代码分⽀纳⼊新功能，能持续的交付产出给下游，让整个项⽬进展⾁眼可见。不过静⼼想想就知道有很多⿇烦事⼉，所以这⼀切就交给专业的⼯具来完成了，Jenkins值得拥有。常用微服务架构
⼗⼆、Docker容器部署
微服务架构⾥，需要快捷启动服务实例，⽀持不同系统环境，不同运⾏环境，不同语⾔的各种服务实例，独⽴的物理服务器是不现实的，虚拟化技术的成本太⾼，快捷的沙箱环境+⾼效的资源利⽤+可复制快速启动的容器Docker 成为⾸选，Build Once,Run AnyWhere!不会docker的程序员，已经不是⼀个好的⼯程师了。
⼗三、容器编排Kubernetes
有了Docker，我们可以肆⽆忌惮轻松惬意的扩充服务实例，乐极⽣悲，容器实例可能会膨胀到你控制不住的地步，可能⼀个⽉后整个团队就没⼈能搞清楚服务和容器间错综复杂的关系了。所以你需要⼀个管理⼯具，那就是Kubernete，⽤于编排容器，是管理应⽤的全⽣命周期的⼯具，可以理解为docker管家。
学习实践微服务架构
能看到这⾥的⼩伙伴⼉，可谓是饱受煎熬了，这么多的框架/组件/⼯具/⽅法，是不是让你望⽽⽣畏了。确实，现在企业要落地微服务架构，对架构师也提出了更⾼的要求和挑战(谁让你拿的钱最多)。下⾯，我来给⼤家分享下如何学习和实践微服务！
第⼀阶段
理解单体架构设计，掌握OOP+AOP的编程设计思想，熟悉DDD领域驱动设计的分析设计⽅法，尝试去简单拆分系统。第⼆阶段
以微服务的思路去重构系统，将⾼频且独⽴的服务拆分，部署集，Consul服务治理，整合⽹关，完成基础微服务架构。
第三阶段
进⼀步完善架构，开始重构鉴权授权、服务追踪、分布式⽇志分析、引⼊配置中⼼等组件，解决分布式锁和分布式事务，做到功能可⽤。
第四阶段
去引⼊新的⼯具完成项⽬部署运营管理，Jenkins/Docker/K8S，⼀步步的纳⼊使⽤，这⾥最省事⼉的办法是上云，阿⾥云、Azure云都值得推荐。
第五阶段
项⽬全⾯微服务化，迈过前⾯的门槛了，后⾯会越来越顺利，在完整项⽬实战中去落地微服务架构，应对各种真实情况。
好了，以上是⼀个循序渐进的学习和实战过程，也是架构班⾥⾯学习微服务架构的全过程，全程需要3个⽉时间，确实不易，不过收获杠杠的！下图是微服务的体验课，⼀周时间了解和实践微服务架构的组件，本⽂的读者直接限时免费领取，赶快扫码和⼤家⼀起交流学习吧！
版权申明：本⽂来源于⽹友收集或⽹友提供，如果有侵权，请转告版主或者留⾔，本⽴即删除。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。