微服务架构必备技术栈：万变不离其宗的奥义！
前言
之前我们说过，微服务是一种软件设计、架构思想。当然，里面也包含了相关技术点要解决当前要务。学习微服务，我们不能空口而谈，一定要落实到具体的技术栈上。
当今使用比较多两个技术体系，一个是 Java，另外一个就是 Net。
废话不多说，今天我就把相关“微服务架构”所用到的技术栈罗列出来。（以下是微软相关技术栈的）
这里也要说明一下，微服务架构里面的很多技术是和开发语言无关的。无论是 .Net 还是 Java 平台都可以使用。我们之前说过，微服务架构的轮廓大同小异，以后，一步一步的针对每项技术在做深入研究。
微服务架构----服务通信
WebService、WCF、WebAPI，甚至可以是 ASHX,ASPX，这都是微软本身的技术体系，没什么可说的。
主动触发
数据序列化传递
跨平台。
跨语言。
Http 穿透防火墙。
微服务架构----进程通信
Net Remoting：Net 平台督邮的，不支持跨平台。
gRPC：高性能、开源和通用 RPC 框架，面向服务端和移动端，基于 HTTP/2 设计，推荐使用。
微服务架构---API 网关服务（Ocelot）
API 网关 —— 它是系统的暴露在外部的一个访问入口。这个有点像代理访问的家伙，就像一个公司的门卫承担着寻址、限制进入、安全检查、位置引导、等等功能。
Ocelot 是一个用.NET Core 实现并且开源的 API 网关，它功能强大，包括了：路由、请求聚合、服务发现、认证、鉴权、限流熔断、并内置了负载均衡器与 Service Fabric、Butterfly Tracing 集成。这些功能只都只需要简单的配置即可完成。如图：
微服务架构---认证 &授权
现在的应用开发层出不穷，基于浏览器的网页应用，基于微信的公众号、小程序，基于 IOS、Android 的 App，基于 Windows 系统的桌面应用和 UWP 应用等等。
这么多种类的应用，就给应用的开发带来的挑战，我们除了分别实现各个应用外，我们还要考虑各个应用之间的交互，通用模块的提炼，其中身份的认证和授权就是每个应用必不可少的的一部分。
而现在的互联网，对于信息安全要求又十分苛刻，所以一套统一的身份认证和授权就至关重要。IdentityServer4 就是这样一个框架，IdentityServer4 是为 ASP.NET CORE 量身定制的实现了 OpenId Connect 和 OAuth2.0 协议的认证授权中间件。
微服务架构---瞬态故障处理
Polly 它一款强大的类库，Polly 是一种.NET 弹性和瞬态故障处理库，允许我们以非常顺畅和线程安全的方式来执诸如行重试，断路，超时，故障恢复等策略。
Polly 针对 .NET 4.0，.NET 4.5 和.NET Standard 1.1 以及.NET Core 实现，该项目作者现已成为.NET 基金会一员，项目一直在不停迭代和更新，你值得拥有。
微服务架构---分布式追踪
随着微服务架构的流行，一些微服务架构下的问题也会越来越突出。
比如一个请求会涉及多个服务，而服务本身可能也会依赖其他服务，整个请求路径就构成了一个网状的调用链，而在整个调用链中一旦某个节点发生异常，整个调用链的稳定性就会受到影响，所以会深深的感受到 “银弹” 这个词是不存在的，每种架构都有其优缺点。
面对以上情况， 我们就需要一些可以帮助理解系统行为、用于分析性能问题的工具，以便发生故障的时候，能够快速定位和解决问题，这时候 APM（应用性能管理）工具就该闪亮登场了。
微服务架构----分布式日志
一般我们需要进行日志分析场景：直接在日志文件中grep、awk 就可以获得自己想要的信息。但在规模较大也就是日志量多而复杂的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。
这就需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
大型系统通常都是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。
Exceptionless 是一个开源的实时的日志收集框架，它可以应用在基于 ASP.NET，ASP.NET Core，Web Api，Web Forms，WPF，Console，MVC 等技术栈的应用程序中，并且提供了 Rest 接口可以应用在 Javascript，Node.js 中。
Exceptionless 将日志收集变得简单易用并且不需要了解太多的相关技术细节及配置。在以前，我们做日志收集大多使用 Log4net，Nlog 等框架，在应用程序变得复杂并且集群的时候，可能传统的方式已经不是很好的适用了，因为收集各个日志并且分析他们将变得麻烦而且浪费时间。现在 Exceptionless 团队给我们提供了一个更好的框架来做这件事情，我认为这是非常伟大并且有意义的，感谢他们。
ELK 是三个开源软件的缩写，分别为：Elasticsearch 、 Logstash 以及 Kibana , 它们都是开源软件。不过现在还新增了一个 Beats，它是一个轻量级的日志收集处理工具(Agent)，Beats 占用资源少，适合于在各个服务器上搜集日志后传输给 Logstash，官方也推荐此工具，目前由于原本的 ELK Stack 成员中加入了 Beats 工具所以已改名为 Elastic Stack。推荐使用。
微服务架构---分布式配置中心
Apollo（阿波罗）是携程框架部门研发的配置管理平台，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性。
服务端基于 Spring Boot 和 Spring Cloud 开发，打包后可以直接运行，不需要额外安装 Tomcat 等应用容器。
Java 客户端不依赖任何框架，能够运行于所有 Java 运行时环境，同时对 Spring 环境也有较好的支持。
.Net 客户端不依赖任何框架，能够运行于所有 .Net 运行时环境。
微服务架构---分布式锁
分布式锁的解决方案有很多，我在这里就罗列一些，我会在以后的实践中实现这些技术点。
Consul 可以实现分布式锁
Redis 可以实现分布式锁，推荐使用。
Zookeeper 可以实现分布式锁
数据库 可以实现分布式锁
微服务架构---分布式事务
分布式事务的实现方式也不少，以后努力学习吧。
2PC（two-phase commit protocol，强一致性，没有可用性）
3PC
TCC（Try-Confirm-Cancel）
本地消息表，推荐 RabbitMQ。
Saga 模式
本地消息表：MQ 分布式事务—本地消息表—基于消息的一致性。
上游投递消息
下游获取消息
上游投递稳定性
下游接受稳定性
微服务架构---容器化
Docker 是一个开源的应用容器引擎，可以打包应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux 和 Windows 机器上，也可以实现虚拟化。
Docker 使用客户端-服务器 (C/S) 架构模式，使用远程 API 来管理和创建 Docker 容器。Docker 容器通过 Docker 镜像来创建。容器与镜像的关系类似于面向对象编程中的对象与类。
Docker 采用 C/S 架构 Docker daemon 作为服务端接受来自客户的请求，并处理这些请求（创建、运行、分发容器）。
客户端和服务端既可以运行在一个机器上，也可通过 socket 或者 RESTful API 来进行通信。Docker daemon 一般在宿主主机后台运行，等待接收来自客户端的消息。Docker 客户端则为用户提供一系列可执行命令，用户用这些命令实现跟 Docker daemon 交互。如图：
微服务架构---容器编排
Kubernetes 是 Google 开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。
在 Kubernetes 中，我们可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问，而这些细节都不需要运维人员去进行复杂的手工配置和处理。
Kubernetes 也可以理解为 Docker 的编排容器，是管理应用的全生命周期的工具，从创建应用/部署，应用提供服务，扩容缩容，更新，都非常的方便，而且可以做到故障自愈。
微服务架构---CI/CD
Jenkins 是一个开源的、提供友好操作界面的持续集成（CI）工具，主要用于持续、自动的构建/测试软件项目、监控外部任务的运行。
文章转载自：二价亚铁.
还未添加个人签名 2023-06-19 加入
还未添加个人简介
评论