微服务技术栈及分享计划

前言

上一篇对微服的演变、优缺点进行了概述，对于业务复杂项目，微服务算是比较合适的解决方案；对于我们开发者来讲，有好的解决方案确定要跟进学习，但不能盲目追崇流行技术，目的仍是为了解决问题。这里就把Asp.NetCore落地微服务架构技术栈汇总一下(固然不限于此)，同时制定了个学习分享计划，和小伙们一块儿共勉；

正文

将涉及的技术栈将其分为以下几个阶段进行归类，后续学习分享的大方向也是如此：

对于需求阶段业务分析、测试阶段相关及最后应用阶段的服务，这系列暂时就先不涉及，而是主要针对开发技术、代码管理、应用部署、运维管理方面的技术进行汇总和学习分享；对于上图的各个阶段，可能在不少大公司将其职责的划分很清晰，但对接避免不了(DevOps)，因此了解和学习是颇有必要的；若是是中小型公司，那可能开发是你、部署是你、运维仍是你，技多不压身，来了就干，不服就来学。

注：不是在项目中使用如下提到的技术就是微服务，而微服务指的是业务之微，技术只是对其进行落地实现；

开发阶段

对于实现，在开发阶段涉及的组件或框架颇多，因此得花更多时间进行学习和实战，以下：

认证中心

当划分的服务增多时，单个服务的认证和受权显得更加冗余，更但愿有一个统一的认证站点，每个服务的认证都由认证中心站点进行认证和受权；我们能够从零本身实现OAuth 2.0和OIDC提供受权和认证功能，轮子确定有人造好了，拿来就用多好，IdentityServer 4将受权和认证都有很好的实现，从而使得开发人员有更多的时间关注在业务开发上。

服务发现

当服务很少的时候，可能手动进行API地址配置，实现调用还能够接受配置复杂性，若是是对服务增长服务器扩展时，还得手动进行配置，那干这活的确定要喷脏话了。若是使用Consul作服务发现，自动发现各个服务，同时还能进行健康检查，及时过滤掉不可用服务，加强高可用，显得更加智能化；减小人工配置的复杂性，还能提高服务的高可用。

网关(Gateway)

网关的主要做用是进行路由转换、统一入口、隔离内网等，固然还能够作一些服务熔断、限流、重试、缓存等相关功能。功能具体是什么意思，怎么实现咱们在作学习分享的时候会一一说到。而.NetCore中经常使用的网关为Ocelot和Kong；

• 路由转换：根据配置规则，将不一样业务地址转换到对应的微服务地址上，让业务请求由对应的业务API进行处理；
• 统一入口：对于UI界面而言，只关心一个入口，即网关地址，不用和每一个微服务直接打交道，下降请求访问复杂性；
• 隔离内网：对外提供地址为网关地址，内部服务通讯都是经过内网，使得站点安全性加强；
• 其余功能会在后续实操中一一说到；

服务间通信

虽然拆分红了各个小服务，但始终仍是一个系统，对于一些业务依赖关系的服务会进行聚合或是经过服务间通讯，将数据整合统一返回给UI层；经常使用的技术手段是经过Restful Api接口或是gRPC进行数据交互，而后再进行数据业务处理。

服务治理

每个小服务也是一个程序，就有可能出现Bug、网络通讯异常、服务器宕机等状况而致使服务不可用，一般咱们理想状态确定是但愿其余服务不被异常服务影响，这样就须要对服务进行治理，好比失败重试、服务熔断、失败降级等，从而提高服务的可用性，避免单个异常服务致使整个系统雪崩的现象；.NetCore中会使用Polly库实现相关功能。

NoSql-非关系型数据库

一般的高并发场景下须要进行缓存和数据共享，实现高可用，而目前Redis是一个很不错的选择。对于一些文档型数据，MongoDB存储更有优点，当有大量数据时，会有一些列存储的数据；对于搜索实现，ElasticSearch存储实现会更加符合场景；

消息队列

消息队列的三大好处：异步处理、解耦、削峰；一般在微服务系统业务处理中，遇到一些复杂业务，须要耗费较长的时间，这样给用户体验就不太友好，我们能够将涉及相关业务经过消息队列分发给不一样服务处理，而后及时响应给用户，业务后台异步处理，体验感受就不同；可能有小伙伴还会说，直接多线程不就得了，若是是这样的话，那业务可能都耦合在一块，后期维护又是一个很大问题；对于一些高并发系统，估计平时服务器都能承载请求，可是存在某一时间段高峰访问，若是请求都打到后台服务数据库，数据库可能抗不住，像这种短时段高峰的状况，能够经过消息队列进行削峰，避免高峰时刻搞崩系统；目前比较经常使用的消息队列有：Kafka、RocketMQ、RabbitMQ。

CAP

微服务就是分布式，既然是分布式，那分布式事务就避免不了，最终数据一致性的问题那得解决；对于分布式来讲，这是老生常谈的问题了，而且提供了相关的解决方案，而在.Net中，有大神就封装了CAP，并将其开源，配合消息队列很好的实现了分布式事务控制；

Apollo

试想，若是每一个服务都有一套本身的配置文件，那部署和运维是否是很头痛，并且对于一些公共配置数据也会重复在每一个服务中配置使用，若是有一套统一的配置中心是否是感受很是良好，全部服务的配置数据经过一个点进行维护和使用，无论在开发维护、部署仍是运维方面，都带来便捷性；能够本身实现，也可使用第三方的，而Apollo如今相对来讲是比较火的，也有一些直接使用Consul扮演配置中心的角色；固然还有使用在K8S自带的配置中心。

后台任务

既然用到微服务项目，应该数据量也不会小，一般会作一些报表分析，数据同步等操做，而这种耗时操做不但愿在业务高峰时期执行，须要在空闲时间定时操做便可，针对这种场景后台定时任务就有用武之地啦。固然不只仅是这种场景，还有一些作业务数据重放或修复，好比一个订单在操做中异步处理失败了，能够在后台任务检查过程当中，进行再次处理等；在.Net中用的相对比较多的是Quartz.Net和Hangfire。

代码管理

代码应该不用多说了，小伙伴们应该都摸清门路了，简单画个图，以下：

代码规范

无论什么架构，代码规范一直是开发者严格要求的，开发过程当中得有良好的编码规范，虽然每个公司的要求不太同样，但最终的目的是一致的：规范化，这样在后期维护就不会花费大量的时间去研究代码为何要这么写。为了规范，周期性的Code Review是必不可少的。

代码版本管理

对于代码版本管理工具，用的最多应该是git和svn了，其中对于分支的管理是很是重要的，好比临时修复线上Bug怎么办，常规开发怎么办，紧急功能开发又怎么划分处理，好的规划代码分支不会让代码版本混乱，从而引发功能的不完整或异常； 别小看这一件事，常常由于版本分支问题致使生产功能出问题的事件比比皆是，固然不会单独为其作一个文章讲解，但会在集成部署那块会提到；由于持续集成离不开代码的管理；

部署

提到部署，可能有的小伙伴会说，这不是运维搞的吗，或者说这不该该有专门的人搞吗？是的，理想是这样的，但事实就是，小伙伴不只负责开发，还得要部署，对于职责分明的团队，至少你也得会，否则对接有一大堆的尴尬。

操做系统

如今部署更多的是推荐在Linux上了，像Redis、ES、nginx等都是在Linux中发挥更好的性能，而对于Linux估计有些小伙伴还不熟，甚至只是据说，还没操做，不说多的，关于开发和部署相关平常操做到时候咱们来一块儿聊聊，高深操做能够抽时间再去研究。固然，Windows的操做到时候也能提到，毕竟如今Windows服务器也没有说不用。

持续集成(CI/CD)

老式的手动发布和部署在微服务中显得力不从心了，那么多服务，作重复操做，换作任何一我的也受不了，若是多发几回迭代，那这人就别干其余活，就负责发布妥了。 想一想，若是这些事自动化解决岂不完美，而Jenkins搭配代码管理软件就能很好的实现，自动拉取代码->自动构建->自动部署，代码管理软件能够本身搭建，好比Gogs，或者使用gitlab、github等都行。经过监听代码的提交，就能自动完成，想一想都美。

容器化

开发和运维干架啦，一个说在我这行，一个说在我那不行， 别说那么多，先干架再说；哈哈哈，为了避免容许这种事发生，容器化显得很屌，开发发布打包生成镜像，运维拉下来就直接跑，啥都同样，还有的说吗；其实主要的目的仍是提高工做效率啊，现现在Docker是火的旺旺的，但K8S的弃用可否让它走下坡路，这彷佛好像不太好说；

容器编排

当容器集群扩展增多时，就得有一个东西进行管理，不然扩展会显得超级麻烦，而K8S就很吃香，针对容器集群管理更好的自动伸缩、自动部署，还能搭配探针实现自修复；

运维

功能开发完了、代码也上传了、站点也部署了，用户开始用吧，后续就很轻松了；no，no，no，这才开始，应该不多有小伙伴拍着胸脯说，没事，我作的功能都没问题，绝对没Bug，好，先假设开发没问题，断电、宕机、断网咋整，这种物理问题不能避免吧，无论是作异地多活也好，仍是有其余方案，至少得去弄吧； 那若是是业务问题呢，排查问题更多的是靠日志了，对于微服务这种架构，有一个调用链的追踪会提供很好的辅助，来，先看看须要什么技术工具：

日志分析

以前单体架构，登上服务器，拷贝日志下来分析妥了，而对于微服务，这彷佛不太可取，拷贝日志不只麻烦还耗时。若是使用Exceptionless将日志统一收集在一块儿，是否是稍微好那么一点，再加上作一个ElasticSearch和Kibana的查询分析，是否是又加快了问题的分析速度。

链路追踪

微服务间的数据交互确定避免不了，有一个可视化的调用链路及监控就显得更加直观，清楚的看到每次接口调用通过的服务点，对于定位问题来讲也提供很大的帮助，能快速知道此次异常通过哪些服务处理，缩小范围。而用的相对比较多的是SkyWalking和Butterfly。

分布式监控系统

微服务状况下，只要一发布，就不知道什么状况，这样只有在问题发生以后，才能去排查；有没有一个监控系统，对系统和服务运行环境进行监控，能在危险范围内的时候提早给个告警，及时通知相关人员处理呢，prometheus搭配Grafana能将监控数据友好的展现和配置，从而实现对服务运行环境的监控。

总结

对于微服务，仍是开篇说到的，不是使用以上技术就是微服务架构，而服务的划分更可能是经过业务进行划分，技术只是帮助其落地；

以上针对于各阶段的技术栈汇总并不涵盖所有，仅仅是当下相对比较火，且周围朋友用的比较多的，有什么好的技术，小伙伴能够分享。

这个战线拉的很长，但确定会坚持学习分享。 期间把Redis系列分享完以后，还会穿插数据库优化系列的文章。

一个被程序搞丑的帅小伙，关注"Code综艺圈"，跟我一块儿学~