一、前言
大家始终都在议论微服务架构，园子外面也有很多对于微服务的文章，前几天也有一些园子的敌人问我微服务架构的一些技术，我这里就整顿了微服务架构的技术栈路线图，这里就分享进去和大家一起探讨学习，同时让老手对微服务相干技术有一个更深刻的理解。
二、技术栈
2.1 工欲善其事，必先利其器
当初互联网流行的年代，互联网产品也层出不穷，受欢迎的互联网产品都有一个比拟牛的技术团队，我这里分享下.net 微服务架构技术栈图如下：
俗话说得好：工欲善其事，必先利其器。一个优良的工程师应该长于应用框架和工具，在微服务这一块的技术选型并非欲速不达，须要通过与日俱增和落地的我的项目能力欠缺。下文我会一一分享技术栈中的次要框架和工具的应用场景，这篇文章就不一一分享实战例子。
2.2 微服务
微服务如何“微”？
微服务，当然外围是主题是“微”，怎么微呢？应该如何微呢？在我刚来杭州的时候接触过一个电商零碎的单体架构，零碎比拟宏大，联合了各种电商该领有的业务逻辑和场景，代码也比拟难于保护，前前后后接手的人也比拟多，代码耦合度太高，改个业务逻辑基本上是牵一发而动全身，跟我上个月分享的对于Asp.Net Core 中IdentityServer4 受权核心之利用实战的文章中的电商零碎最后的架构图相似，如下：
那针对这个架构就有可“微”之谈了。
这里针对该单体架构能够做如下几个原则上进行“微”服务:
依据业务来进行拆分，一个业务一个服务准则进行拆分，做到通用性业务服务模块，这样业务之间能够做到高内聚低耦合。前面随便改变哪一块业务，只须要去改变这一块的业务微服务即可，其余业务不会受到影响。
一个业务模块一个独立的数据库为准则，互相平行的业务做到不须要相互依赖调用。
外层API网关进行业务逻辑的整合。
一个业务数据库一个微服务为准则。
联合分布式服务，能够疾速版本迭代，公布平滑公布，不受工夫影响，没时每刻都能够公布，无需中午等到12点进行公布。（比拟苦楚的公布，犹如三日凌空般(有点夸大)，已经有段时间是每周都有那么几个早晨苦楚的公布，一公布就可能是凌晨4，5点，很多时候公布完，还要通过各种测试，最初发现问题还得线上改bug，咱们回去的时候别的共事曾经来下班了；过后咱们的技术大佬说过这么一句话：“他间断一周都没看到过他的儿子，回去的时候，他儿子早就睡着了，起来下班的时候，他儿子曾经去学校了”，大家肯定也有过这样的公布经验。）
依照下面的准则后，原来的电商单体架构微服务革新降级后架构图如下：
架构图粗略的画了下，可能表明意思即可，微服务、Docker、k8s那一块简要的概括，没有具体画出具体的图。
微服务集群
微服务曾经“微”好了，那须要一个服务发现的数据中心，这里就该用到Consul了，Consul次要用来注册服务，及服务发现，以及服务的健康检查，咱们能够依据须要针对某些业务服务进行主动扩容，增加服务器及扩张服务集群，一台服务挂了，Consul会主动抉择可用的服务节点进行连贯应用，这样整体电商零碎稳定性大大增大。须要理解Consul更加具体的个性和搭建，能够点击5分钟看懂微服务架构下的Consul 个性及搭建 一文浏览。
微服务如何保证数据的一致性
以前单体架构利用，对于业务之间的耦合是通过事务保证数据的一致性的，那对于微服务而言怎么做到数据的一致性呢？下面也说了，微服务应该做到业务之间没有依赖关系，每一个业务都是独立的一个服务，那这样怎么保障业务与之间的数据的一致性也存在很大的一个问题，也是业界对微服务争议比拟大的一个话题，那到底该如何保证数据的一致性？
在分布式系统架构中有一个CAP实践：任何分布式系统只可同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）中的两点，没法三者兼顾。对于分布式系统来说，分区容错性是根本要求，否则就失去了价值。因而，就只能在可用性和一致性之间做出抉择。如果抉择提供一致性须要付出在满足一致性之前阻塞其余并发拜访的代价。这可能继续一个不确定的工夫，尤其是在零碎曾经体现出高提早时或者网络故障导致失去连贯时。根据目前的成功经验，可用性个别是更好的抉择，然而在服务和数据库之间保护数据一致性是十分基本的需要，微服务架构中抉择满足最终一致性。
最终一致性是指零碎中的所有数据正本通过一段时间后，最终可能达到统一的状态。这里所说的一段时间，也要是用户可承受范畴内的一段时间。
从一致性的实质来看，就是在一个业务逻辑中蕴含的所有服务要么都胜利，要么都失败。那咱们又该如何抉择方向，来保障胜利还是保障失败呢？就是就须要依据业务模式做出抉择。实现最终一致性有三种模式：牢靠事件模式、业务弥补模式、TCC模式，这里就不再延长，前面有机会再来分享学习。
2.3 微服务开源框架
我这里微服务架构应用的是开源微服务框架 core-grpc 开源框架源代码地址：后面我分享过一篇对于 【.net core】电商平台降级之微服务架构利用实战（core-grpc）中简略形容了微服务的基本概念和利弊，这里就不再分享，具体利用也能够点击【.net core】电商平台降级之微服务架构利用实战（core-grpc） 浏览
2.4 ORM框架
微服务中应用的ORM Dapper ，而应用的的第三方开源组件是core-data，开源作者对dapper 进行了一次封装，开源框架源代码地址
core-data次要劣势：
官网倡议应用DDD 畛域驱动设计思维开发
反对多种数据库，简略配置增加链接的配置即可
多数据库的反对
反对分表操作，自定义分表策略的反对
反对表达式形式编写，缩小写Sql语句机械性工作
可对Dapper 进行扩大
性能依赖于Dapper 自身的性能，Dapper 自身是轻量级ORM ，官网测试性能都强于其余的ORM
2.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 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容器，把.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 拉起镜像、启动我的项目等系列自动化脚本解决，能够平滑的一台一台服务进行并且更新；所有操作无需人为的干涉，甚至呈现问题能够一键回滚操作。
自动化集成部署有哪些劣势
所有自动化，无需人为干涉，提高效率，业余的人做业余的事件，开发做好开发的事件即可，运维做好运维的事件。
公布可追溯
随时人为干涉回滚（通过脚本回顾上一步自动化备份的我的项目镜像）
平滑公布，不影响用户体验，一台一台服务器切断，公布更新。
三、结束语
如果本文对你有帮忙，别忘记给我个3连 ，点赞，转发，评论，
咱们下期见！答案获取形式：已赞 已评 已关~
学习更多JAVA常识与技巧，关注与私信博主（666）