.Net微服务架构技术栈的那些事
⼀、前⾔
⼤家⼀直都在谈论微服务架构，园⼦⾥⾯也有很多关于微服务的⽂章，前⼏天也有⼀些园⼦的朋友问我微服务架构的⼀些技术，我这⾥就整理了微服务架构的技术栈路线图，这⾥就分享出来和⼤家⼀起探讨学习，同时让新⼿对微服务相关技术有⼀个更深⼊的了解。
⼆、技术栈
2.1 ⼯欲善其事，必先利其器
现在互联⽹盛⾏的年代，互联⽹产品也层出不穷，受欢迎的互联⽹产品都有⼀个⽐较⽜的技术团队，我这⾥分享下 微服务架构技术栈图如下：
俗话说得好：⼯欲善其事，必先利其器。⼀个优秀的⼯程师应该善于使⽤框架和⼯具，在微服务这⼀块的技术选型并⾮⼀蹴⽽就，需要经过⽇积⽉累和落地的项⽬才能完善。
下⽂我会⼀⼀分享技术栈中的主要框架和⼯具的使⽤场景，这篇⽂章就不⼀⼀分享实战例⼦。
2.2 微服务
微服务如何“微”？
微服务，当然核⼼是主题是“微”，怎么微呢？应该如何微呢？在我刚来杭州的时候接触过⼀个电商系统的单体架构，系统⽐较庞⼤，结合了各种电商该拥有的业务逻辑和场景，
代码也⽐较难于维护，前前后后接⼿的⼈也⽐较多，代码耦合度太⾼，改个业务逻辑基本上是牵⼀发⽽动全⾝，跟我上个⽉分享的关于
的⽂章中的电商系统最初的架构图类似，如下：
那针对这个架构就有可“微”之谈了。
这⾥针对该单体架构可以做如下⼏个原则上进⾏“微”服务:
根据业务来进⾏拆分，⼀个业务⼀个服务原则进⾏拆分，做到通⽤性业务服务模块，这样业务之间可以做到⾼内聚低耦合。后⾯随意改动哪⼀块业务，只需要去改动这⼀块的业务微服务即可，其他业务不会受到影响。
⼀个业务模块⼀个独⽴的数据库为原则，相互平⾏的业务做到不需要相互依赖调⽤。
外层API⽹关进⾏业务逻辑的整合。
⼀个业务数据库⼀个微服务为原则。
结合分布式服务，可以快速版本迭代，发布平滑发布，不受时间影响，没时每刻都可以发布，⽆需半夜等到12点进⾏发布。（⽐较痛苦的发布，犹如三⽇凌空般(有点夸张)，曾经有段时间是每周都有那么⼏个晚上痛苦的发布，⼀发布就可能是凌晨4，5点，很多时候发布完，还要经过各种测试，最后发现问题还得线上改bug，我们回去的时候别的同事已经来上班了；当时我们的技术⼤佬说过这么⼀句话：“他连续⼀周都没看到过他的⼉⼦，回去的时候，他⼉⼦早就睡着了，起来上班的时候，他⼉⼦已经去学校了”，⼤家⼀定也有过这样的发布经历。）
按照上⾯的原则后，原来的电商单体架构微服务改造升级后架构图如下：
架构图粗略的画了下，能够表明意思即可，微服务、Docker、k8s那⼀块简要的概括，没有详细画出具体的图。
微服务集
微服务已经“微”好了，那需要⼀个服务发现的数据中⼼，这⾥就该⽤到Consul了，Consul主要⽤来注册服务，及服务发现，以及服务的健康检查，我们可以根据需要针对某些业务服务进⾏⾃动扩容，添加服务器及扩张服务集，⼀台服务挂了，Consul会⾃动选择可⽤的服务节点进⾏连接使⽤，这样整体电商系统稳定性⼤⼤增⼤。
需要了解Consul更加详细的特性和搭建，可以点击⼀⽂阅读。
微服务如何保证数据的⼀致性
以前单体架构应⽤，对于业务之间的耦合是通过事务保证数据的⼀致性的，那对于微服务⽽⾔怎么做到数据的⼀致性呢？上⾯也说了，微服务应该做到业务之间没有依赖关系，每⼀个业务都是独⽴的⼀个服务，那这样怎么保证业务与之间的数据的⼀致性也存在很⼤的⼀个问题，也是业界对微服务争议⽐较⼤的⼀个话题，那到底该如何保证数据的⼀致性？
在分布式系统架构中有⼀个CAP理论：任何分布式系统只可同时满⾜⼀致性（Consistency）、可⽤性（Availability）、分区容错性（Partition tolerance）中的两点，没法三者兼顾。对于分布式系统来说，分区容错性是基本要求，否则就失去了价值。因此，就只能在可⽤性和⼀致性之间做出选择。如果选择提供⼀致性需要付出在满⾜⼀致性之前阻塞其他并发访问的代价。这可能持续⼀个不确定的时间，尤其是在系统已经表现出⾼延迟时或者⽹络故障导致失去连接时。依据⽬前的成功经验，可⽤性⼀般是更好的选择，但是在服务和数据库之间维护数据⼀致性是⾮常根本的需求，微服务架构中选择满⾜最终⼀致性。
最终⼀致性是指系统中的所有数据副本经过⼀段时间后，最终能够达到⼀致的状态。
这⾥所说的⼀段时间，也要是⽤户可接受范围内的⼀段时间。
从⼀致性的本质来看，就是在⼀个业务逻辑中包含的所有服务要么都成功，要么都失败。那我们⼜该如何选择⽅向，来保证成功还是保证失
败呢？就是就需要根据业务模式做出选择。实现最终⼀致性有三种模式：可靠事件模式、业务补偿模式、TCC模式，这⾥就不再延伸，后⾯有机会再来分享学习。
2.3 微服务开源框架
2.4 ORM框架
core-data主要优势：
官⽅建议使⽤DDD 领域驱动设计思想开发
⽀持多种数据库，简单配置添加链接的配置即可
多数据库的⽀持
⽀持分表操作，⾃定义分表策略的⽀持
⽀持表达式⽅式编写，减少写Sql语句机械性⼯作
可对Dapper 进⾏扩展
性能依赖于Dapper 本⾝的性能，Dapper 本⾝是轻量级ORM ，官⽅测试性能都强于其他的ORM
2.5 分布式跟踪系统
随着微服务架构的流⾏，⼀些微服务架构下的问题也会越来越突出，⽐如⼀个请求会涉及多个服务，⽽服务本⾝可能也会依赖其他服务，整个请求路径就构成了⼀个⽹状的调⽤链，⽽在整个调⽤链中⼀旦某个节点发⽣异常，整个调⽤链的稳定性就会受到影响，所以会深深的感受到 “银弹” 这个词是不存在的，每种架构都有其优缺点。
对以上情况，我们就需要⼀些可以帮助理解系统⾏为、⽤于分析性能问题的⼯具，以便发⽣故障的时候，能够快速定位和解决问题，这时候APM（应⽤性能管理）⼯具就该闪亮登场了。
⽬前主要的⼀些 APM ⼯具有: Cat、Zipkin、Pinpoint、SkyWalking，这⾥主要介绍 SkyWalking ，它是⼀款优秀的国产 APM ⼯具，包括了分布式追踪、性能指标分析、应⽤和服务依赖分析等。
2.6 系统⽇志集成
庞⼤的系统中离不开⽇志系统，排查问题，记录相关敏感信息等都需要⼀个⽇志系统，这⾥选择使⽤E
xceptionLess ⽇志系统，⽇志写⼊到ES中，并⽀持可视化UI进⾏⽇志管理，查询，平常遇到问题，直接通过⽇志管理后台进⾏排查。
2.7 消息队列
消息队列中间件是分布式系统中重要的组件，主要解决应⽤耦合，异步消息，流量削锋等问题。实现⾼性能、⾼可⽤、可伸缩和最终⼀致性架构。使⽤较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。
2.8 任务调度
这⾥主要使⽤的是Quartz.Net 进⾏作业任务调度，任务调⽤有什么⽤处呢？，⽐如我们需要统计⼀个数据，但是实时统计需要⼀⼤堆的连表查询，并且⽐较损耗数据库的性能，因此可以选择使⽤任务调度的⽅案进⾏数据统计作业，半夜某个时间点去统计前⼀天的数据。
2.9 NoSql
Nosql 主要是⾮关系型数据库，⽐如MongDB、 Redis、Memcache等，可以⽤来在API⽹关和数据库层⾯做⼀层数据缓存，访问⼀些不是经常更新的数据，把它缓存起来，每次⽹络请求过来就可以先通过从分布式缓存中进⾏数据读取，减少对数据库的查询压⼒，提⾼系统的吞吐量。
2.10 可视化数据管理及分析（Kibana）
Kibana 是为 Elasticsearch设计的开源分析和可视化平台。你可以使⽤ Kibana 来搜索，查看存储在 Elasticsearch 索引中的数据并与之交互。你可以很容易实现⾼级的数据分析和可视化，以图标的形式展现出来。
Kibana 的使⽤场景，应该集中在两⽅⾯：
实时监控
通过 histogram ⾯板，配合不同条件的多个 queries 可以对⼀个事件⾛很多个维度组合出不同的时间序列⾛势。时间序列数据是最常见的监控报警了。
问题分析
关于 elk 的⽤途，可以参照其对应的商业产品 splunk 的场景：使⽤ Splunk 的意义在于使信息收集和处理智能化。⽽其操作智能化表现在：搜索，通过下钻数据排查问题，通过分析根本原因来解决问题；
实时可见性，可以将对系统的检测和警报结合在⼀起，便于跟踪 SLA 和性能问题；
历史分析，可以从中出趋势和历史模式，⾏为基线和阈值，⽣成⼀致性报告。
2.11 Prometheus
Prometheus是⼀套开源的系统监控报警框架。Prometheus作为新⼀代的云原⽣监控系统，相⽐传统监控监控系统（Nagios或者Zabbix）拥有如下优点。
优势
易于管理
轻易获取服务内部状态
⾼效灵活的查询语句
⽀持本地和远程存储
采⽤http协议，默认pull模式拉取数据，也可以通过中间⽹关push数据
⽀持⾃动发现
可扩展
易集成
好了到了这⾥，⼤多已经介绍完了，其他⼏个⼤家都是⽐较常见常使⽤的技术，就不⼀⼀介绍了。
2.12 .Net Core 虚拟化
.Net Core 新⼀代的.Net Core 跨平台开发框架，可以脱离windows 环境，搭建在linux等平台上，那怎样搭建呢？当然可以使⽤当前⽐较流⾏的Docker容器，把 core 项⽬虚拟化搭建在Docker 容器中运⾏，不依赖于任何平台和环境，只需要通过命令制作好镜像即可，同时也可以借助K8s来进⾏多容器应⽤部署、编排、更新等。
微服务注册中心有哪些什么是k8s呢？
Kubernetes是⼀个开源的，⽤于管理云平台中多个主机上的容器化的应⽤，Kubernetes的⽬标是让部署容器化的应⽤简单并且⾼效（powerful）,Kubernetes提供了应⽤部署，规划，更新，维护的⼀种机制。
Kubernetes⼀个核⼼的特点就是能够⾃主的管理容器来保证云平台中的容器按照⽤户的期望状态运⾏着（⽐如⽤户想让apache⼀直运⾏，⽤户不需要关⼼怎么去做，Kubernetes会⾃动去监控，然后去重启，新建，总之，让apache⼀直提供服务），管理员可以加载⼀个微型服务，让规划器来到合适的
位置，同时，Kubernetes也系统提升⼯具以及⼈性化⽅⾯，让⽤户能够⽅便的部署⾃⼰的应⽤（就像canary deployments）。
现在Kubernetes着重于不间断的服务状态（⽐如web服务器或者缓存服务器）和原⽣云平台应⽤（Nosql），在不久的将来会⽀持各种⽣产云平台中的各种服务，例如，分批，⼯作流，以及传统数据库。
在Kubenetes中，所有的容器均在Pod中运⾏,⼀个Pod可以承载⼀个或者多个相关的容器，在后边的案例中，同⼀个Pod中的容器会部署在同⼀个物理机器上并且能够共享资源。⼀个Pod也可以包含O个或者多个磁盘卷组（volumes），这些卷组将会以⽬录的形式提供给⼀个容器，或者被所有Pod中的容器共享，对于⽤户创建的每个Pod，系统会⾃动选择那个健康并且有⾜够容量的机器，然后创建类似容器的容器，当容器创建失败的时候，容器会被node agent⾃动的重启，这个node agent叫kubelet，但是，如果是Pod失败或者机器，它不会⾃动的转移并且启动，除⾮⽤户定义了 replication controller。
⽤户可以⾃⼰创建并管理Pod,Kubernetes将这些操作简化为两个操作：基于相同的Pod配置⽂件部署多个Pod复制品；创建可替代的Pod当⼀个Pod挂了或者机器挂了的时候。⽽Kubernetes API中负责来重新启动，迁移等⾏为的部分叫做“replication controller”，它根据⼀个模板⽣成了⼀个Pod，然后系统就根据⽤户的需求创建了许多冗余，这些冗余的Pod组成了⼀个整个应⽤，或者服务，或者服务中的
⼀层。⼀旦⼀个Pod被创建，系统就会不停的监控Pod的健康情况以及Pod所在主机的健康情况，如果这个Pod因为软件原因挂掉了或者所在的机器挂掉了，replication controller 会⾃动在⼀个健康的机器上创建⼀个⼀摸⼀样的Pod，来维持原来的Pod冗余状态不变，⼀个应⽤的多个Pod可以共享⼀个机器。
我们经常需要选中⼀组Pod，例如，我们要限制⼀组Pod的某些操作，或者查询某组Pod的状态，作为Kubernetes的基本机制，⽤户可以给Kubernetes Api中的任何对象贴上⼀组 key:value的标签，然后，我们就可以通过标签来选择⼀组相关的Kubernetes Api 对象，然后去执⾏⼀些特定的操作，每个资源额外拥有⼀组（很多） keys 和 values，然后外部的⼯具可以使⽤这些keys和vlues值进⾏对象的检索，这些Map 叫做annotations（注释）。
Kubernetes⽀持⼀种特殊的⽹络模型，Kubernetes创建了⼀个地址空间，并且不动态的分配端⼝，它可以允许⽤户选择任何想使⽤的端⼝，为了实现这个功能，它为每个Pod分配IP地址。
现代互联⽹应⽤⼀般都会包含多层服务构成，⽐如web前台空间与⽤来存储键值对的内存服务器以及对应的存储服务，为了更好的服务于这样的架构，Kubernetes提供了服务的抽象，并提供了固定的IP地址和DNS名称，⽽这些与⼀系列Pod进⾏动态关联，这些都通过之前提到的标签进⾏关联，所以我们可以关联任何我们想关联的Pod，当⼀个Pod中的容器访问这个地址的时候，这个请求会被转发到本
地代理（kube proxy），每台机器上均有⼀个本地代理，然后被转发到相应的后端容器。Kubernetes通过⼀种轮训机制选择相应的后端容器，这些动态的Pod被替换的时候,Kube proxy时刻追踪着，所以，服务的 IP地址（dns名称），从来不变。
所有Kubernetes中的资源，⽐如Pod，都通过⼀个叫URI的东西来区分，这个URI有⼀个UID,URI的重要组成部分是：对象的类型（⽐如pod），对象的名字，对象的命名空间，对于特殊的对象类型，在同⼀个命名空间内，所有的名字都是不同的，在对象只提供名称，不提供命名空间的情况下，这种情况是假定是默认的命名空间。UID是时间和空间上的唯⼀。
2.13 ⾃动化集成部署
为什么需要⾃动化集成部署？
我从以下⼏点来分析为什么需要⾃动化集成部署：
你要相信的是所有的⼈⼯部署、发布、更新都是不可靠的，⾃动化智能部署可以减少事故率。
⼈为备份、发布更新都是效率⾮常低的。
如果某个项⽬需要更新，但是这个微服务有⼗⼏台负载，那你⼈为⼀台⼀台服务器更新发布是不是很繁琐，更加容易出事故呢？
什么是⾃动化集成部署？
通过jenkins、gitlab、docker等⼯具，以及依赖事先写好的脚本监听代码提交动态、⾃动化构造项⽬镜像、推送镜像到镜像仓库、Docker 拉起镜像、启动项⽬等系列⾃动化脚本处理，可以平滑的⼀台⼀台服务停⽌并且更新；⼀切操作⽆需⼈为的⼲预，甚⾄出现问题可以⼀键回滚操作。
⾃动化集成部署有哪些优势
⼀切⾃动化，⽆需⼈为⼲预，提⾼效率，专业的⼈做专业的事情，开发做好开发的事情即可，运维做好运维的事情。
发布可追溯
随时⼈为⼲预回滚（通过脚本回顾上⼀步⾃动化备份的项⽬镜像）
平滑发布，不影响⽤户体验，⼀台⼀台服务器切断，发布更新。
三、结束语
今天写的有点多了，画了⼀张图就停不下来了，本⽂分析了 core 微服务架构中⽤到的系列技术使
⽤场景和⽤途，没有⼀点实战性东西，⽬的是让⼩⽩有⼀个明确的技术⽅向，进⼀步掌握微服务架构相关的技术；也让⾃⼰对以往的经验进⾏梳理和总结，这样才能朝着更⼤的⽬标前进。后⾯我会持续给⼤家带来更多的⼲货和实战性东西，欢迎关注【dotNET博⼠】
转载:wwwblogs/jlion/p/12635845.html

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