内部网站建设软件下载,南昌房产网信息网,网站建设开发网站案例项目费用,在邯郸开互联网公司一、前言大家一直都在谈论微服务架构#xff0c;园子里面也有很多关于微服务的文章#xff0c;前几天也有一些园子的朋友问我微服务架构的一些技术#xff0c;我这里就整理了微服务架构的技术栈路线图#xff0c;这里就分享出来和大家一起探讨学习#xff0c;同时让新手对… 一、前言 大家一直都在谈论微服务架构园子里面也有很多关于微服务的文章前几天也有一些园子的朋友问我微服务架构的一些技术我这里就整理了微服务架构的技术栈路线图这里就分享出来和大家一起探讨学习同时让新手对微服务相关技术有一个更深入的了解。二、技术栈2.1 工欲善其事必先利其器现在互联网盛行的年代互联网产品也层出不穷受欢迎的互联网产品都有一个比较牛的技术团队我这里分享下.net 微服务架构技术栈图如下俗话说得好工欲善其事必先利其器。一个优秀的工程师应该善于使用框架和工具在微服务这一块的技术选型并非一蹴而就需要经过日积月累和落地的项目才能完善。下文我会一一分享技术栈中的主要框架和工具的使用场景这篇文章就不一一分享实战例子。2.2 微服务微服务如何“微”微服务当然核心是主题是“微”怎么微呢应该如何微呢在我刚来杭州的时候接触过一个电商系统的单体架构系统比较庞大结合了各种电商该拥有的业务逻辑和场景 代码也比较难于维护前前后后接手的人也比较多代码耦合度太高改个业务逻辑基本上是牵一发而动全身跟我上个月分享的关于Asp.Net Core 中IdentityServer4 授权中心之应用实战的文章中的电商系统最初的架构图类似如下那针对这个架构就有可“微”之谈了。这里针对该单体架构可以做如下几个原则上进行“微”服务:根据业务来进行拆分一个业务一个服务原则进行拆分做到通用性业务服务模块这样业务之间可以做到高内聚低耦合。后面随意改动哪一块业务只需要去改动这一块的业务微服务即可其他业务不会受到影响。一个业务模块一个独立的数据库为原则相互平行的业务做到不需要相互依赖调用。外层API网关进行业务逻辑的整合。一个业务数据库一个微服务为原则。结合分布式服务可以快速版本迭代发布平滑发布不受时间影响每时每刻都可以发布无需半夜等到12点进行发布。比较痛苦的发布犹如三日凌空般有点夸张曾经有段时间是每周都有那么几个晚上痛苦的发布一发布就可能是凌晨45点很多时候发布完还要经过各种测试最后发现问题还得线上改bug我们回去的时候别的同事已经来上班了当时我们的技术大佬说过这么一句话“他连续一周都没看到过他的儿子回去的时候他儿子早就睡着了起来上班的时候他儿子已经去学校了”大家一定也有过这样的发布经历。按照上面的原则后原来的电商单体架构微服务后架构图如下架构图粗略的画了下能够表明意思即可微服务、Docker、k8s那一块简要的概括没有详细画出具体的图。微服务集群微服务已经“微”好了那需要一个服务发现的数据中心这里就该用到Consul了Consul主要用来注册服务及服务发现以及服务的健康检查我们可以根据需要针对某些业务服务进行自动扩容添加服务器及扩张服务集群一台服务挂了Consul会自动选择可用的服务节点进行连接使用这样整体电商系统稳定性大大增大。需要了解Consul更加详细的特性和搭建可以点击5分钟看懂微服务架构下的Consul 特性及搭建 一文阅读。微服务如何保证数据的一致性以前单体架构应用对于业务之间的耦合是通过事务保证数据的一致性的那对于微服务而言怎么做到数据的一致性呢上门也说了微服务应该做到业务之间没有依赖关系每一个业务都是独立的一个服务那这样怎么保证业务与之间的数据的一致性也存在很大的一个问题也是业界对微服务争议比较大的一个话题那到底该如何保证数据的一致性在分布式系统架构中有一个CAP理论任何分布式系统只可同时满足一致性Consistency、可用性Availability、分区容错性Partition tolerance中的两点没法三者兼顾。对于分布式系统来说分区容错性是基本要求否则就失去了价值。因此就只能在可用性和一致性之间做出选择。如果选择提供一致性需要付出在满足一致性之前阻塞其他并发访问的代价。这可能持续一个不确定的时间尤其是在系统已经表现出高延迟时或者网络故障导致失去连接时。依据目前的成功经验可用性一般是更好的选择但是在服务和数据库之间维护数据一致性是非常根本的需求微服务架构中选择满足最终一致性。最终一致性是指系统中的所有数据副本经过一段时间后最终能够达到一致的状态。这里所说的一段时间也要是用户可接受范围内的一段时间。从一致性的本质来看就是在一个业务逻辑中包含的所有服务要么都成功要么都失败。那我们又该如何选择方向来保证成功还是保证失败呢就是就需要根据业务模式做出选择。实现最终一致性有三种模式可靠事件模式、业务补偿模式、TCC模式这里就不再延伸后面有机会再来分享学习。2.3 微服务开源框架我这里微服务架构使用的是开源微服务框架 core-grpc 开源框架源代码地址https://github.com/overtly/core-grpc 前面我分享过一篇关于微服务架构应用实战中简单描述了微服务的基本概念和利弊这里就不再分享具体应用也可以点击【.net core】电商平台升级之微服务架构应用实战core-grpc 阅读2.4 ORM框架微服务中使用的ORM Dapper 而使用的的第三方开源组件是core-data开源作者对dapper 进行了一次封装开源框架源代码地址https://github.com/overtly/core-datacore-data主要优势官方建议使用DDD 领域驱动设计思想开发支持多种数据库简单配置添加链接的配置即可多数据库的支持支持分表操作自定义分表策略的支持支持表达式方式编写减少写Sql语句机械性工作可对Dapper 进行扩展性能依赖于Dapper 本身的性能Dapper 本身是轻量级ORM 官方测试性能都强于其他的ORM2.5 分布式跟踪系统随着微服务架构的流行一些微服务架构下的问题也会越来越突出比如一个请求会涉及多个服务而服务本身可能也会依赖其他服务整个请求路径就构成了一个网状的调用链而在整个调用链中一旦某个节点发生异常整个调用链的稳定性就会受到影响所以会深深的感受到 “银弹” 这个词是不存在的每种架构都有其优缺点 。对以上情况 我们就需要一些可以帮助理解系统行为、用于分析性能问题的工具以便发生故障的时候能够快速定位和解决问题这时候 APM应用性能管理工具就该闪亮登场了。目前主要的一些 APM 工具有: Cat、Zipkin、Pinpoint、SkyWalking这里主要介绍 SkyWalking 它是一款优秀的国产 APM 工具包括了分布式追踪、性能指标分析、应用和服务依赖分析等。2.6 系统日志集成庞大的系统中离不开日志系统排查问题记录相关敏感信息等都需要一个日志系统这里选择使用ExceptionLess 日志系统日志写入到ES中并支持可视化UI进行日志管理查询平常遇到问题直接通过日志管理后台进行排查。2.7 消息队列消息队列中间件是分布式系统中重要的组件主要解决应用耦合异步消息流量削锋等问题。实现高性能、高可用、可伸缩和最终一致性架构。使用较多的消息队列有ActiveMQ、RabbitMQ、ZeroMQ、Kafka、MetaMQ、RocketMQ。2.8 任务调度这里主要使用的是Quartz.Net 进行作业任务调度任务调用有什么用处呢比如我们需要统计一个数据但是实时统计需要一大堆的连表查询并且比较损耗数据库的性能因此可以选择使用任务调度的方案进行数据统计作业半夜某个时间点去统计前一天的数据。2.9 NoSqlNosql 主要是非关系型数据库比如MongDB、 Redis、Memcache等可以用来在API网关和数据库层面做一层数据缓存访问一些不是经常更新的数据把它缓存起来每次网络请求过来就可以先通过从分布式缓存中进行数据读取减少对数据库的查询压力提高系统的吞吐量。2.10 可视化数据管理及分析KibanaKibana 是为 Elasticsearch设计的开源分析和可视化平台。你可以使用 Kibana 来搜索查看存储在 Elasticsearch 索引中的数据并与之交互。你可以很容易实现高级的数据分析和可视化以图标的形式展现出来。Kibana 的使用场景应该集中在两方面实时监控 通过 histogram 面板配合不同条件的多个 queries 可以对一个事件走很多个维度组合出不同的时间序列走势。时间序列数据是最常见的监控报警了。问题分析关于 elk 的用途可以参照其对应的商业产品 splunk 的场景使用 Splunk 的意义在于使信息收集和处理智能化。而其操作智能化表现在搜索通过下钻数据排查问题通过分析根本原因来解决问题实时可见性可以将对系统的检测和警报结合在一起便于跟踪 SLA 和性能问题历史分析可以从中找出趋势和历史模式行为基线和阈值生成一致性报告。2.11 PrometheusPrometheus是一套开源的系统监控报警框架。Prometheus作为新一代的云原生监控系统相比传统监控监控系统Nagios或者Zabbix拥有如下优点。优势易于管理轻易获取服务内部状态高效灵活的查询语句支持本地和远程存储采用http协议默认pull模式拉取数据也可以通过中间网关push数据支持自动发现可扩展易集成好了到了这里大多已经介绍完了其他几个大家都是比较常见常使用的技术就不一一介绍了。2.12 .Net Core 虚拟化.Net Core 新一代的.Net Core 跨平台开发框架可以脱离windows 环境搭建在linux等平台上那怎样搭建呢当然可以使用当前比较流行的Docker容器把.net 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 拉起镜像、启动项目等系列自动化脚本处理可以平滑的一台一台服务停止并且更新一切操作无需人为的干预甚至出现问题可以一键回滚操作。自动化集成部署有哪些优势一切自动化无需人为干预提高效率专业的人做专业的事情开发做好开发的事情即可运维做好运维的事情。发布可追溯随时人为干预回滚通过脚本回顾上一步自动化备份的项目镜像平滑发布不影响用户体验一台一台服务器切断发布更新。三、结束语今天写的有点多了画了一张图就停不下来了本文分析了.net core 微服务架构中用到的系列技术使用场景和用途没有一点实战性东西目的是让小白有一个明确的技术方向进一步掌握微服务架构相关的技术也让自己对以往的经验进行梳理和总结这样才能朝着更大的目标前进。后面我会持续给大家带来更多的干货和实战性东西欢迎关注【dotNET博士】微信公众号往期精彩回顾【.net core】电商平台升级之微服务架构应用实战Asp.Net Core 中IdentityServer4 授权中心之应用实战Asp.Net Core 中IdentityServer4 授权中心之自定义授权模式Asp.Net Core 中IdentityServer4 授权流程及刷新TokenAsp.Net Core 中IdentityServer4 实战之 Claim详解Asp.Net Core 中IdentityServer4 实战之角色授权详解Asp.Net Core 中间件应用实战中你不知道的那些事Asp.Net Core Filter 深入浅出的那些事-AOPAsp.Net Core EndPoint 终结点路由工作原理解读ASP.NET CORE 内置的IOC解读及使用♥ 给个[在看]是对我最大的支持 ♥
