微服务的简介和技术栈
这些年的软件设计规模不断扩大,业务需求日益复杂,为了满足系统的高性能、高吞吐率、高稳定性及高扩展性等特性,对软件架构提出了更高的要求。可以说业务需求是驱动软件架构能力的核心动力之一,由于这些因素的变化导致了软件架构思想及相关技术发生重大变革。这些变化在软件架构行业中体现为越来越多的新术语不断涌现,比如："分布式"、“SOA”、“微服务”、“中台”等概念应运而生。今天我就把我学习微服务的经历进行详细记录,包括所有技术实现的具体细节和个人的理解总结。好记性不如烂笔头,以防自己遗忘,日后查阅时也能起到抛砖引玉的作用。当然,这其中许多内容都是个人的理解与总结,所绘制的插图也是本人亲手完成的,可能存在一些不够准确的地方,恳请业内专家不吝赐教,共同进步。
当前科技领域呈现出日新月异的发展态势，并展现出快速演进的特点。相比之下，在软件设计行业正经历着根本性的转变，在这一过程中业务范围不断扩大并日益复杂化，需求规模持续扩大且内容日益丰富。软件架构和部署模式也经历了翻天覆地的变化，在这一领域中"微服务架构"作为一种重要的设计理念正在逐步发展和完善中。以下将简要介绍其发展进程中的主要阶段（仅为个人观点）。
第一阶段：单体架构（Monolithic） 单体架构时代：从系统设计的角度来看，在这种模式下所有的功能都被整合到同一个进程中运行。这种设计理念强调系统的完整性和协同性，并通过统一管理实现对资源的有效控制与优化配置。（如图所示：）
第二阶段：逐渐向多组件化转型 在这一阶段中，“微服务架构”的雏形开始显现。开发团队逐渐认识到单一进程中处理所有功能会导致性能瓶颈与维护难度上升的问题，并开始尝试将系统划分为多个相对独立的服务模块。（如图所示：）
第三阶段：完全实现微服务 在经历了前两个阶段的基础积累后，“微服务架构”最终实现了对传统单体架构的根本性转变。“微服务”的核心理念在于通过模块化的设计思想将复杂的系统分解成多个功能相对独立的服务单元，并通过标准化接口实现各服务之间的高效通信与协作。（这些观点仅代表个人见解，并非官方立场。）
优点：系统的架构设计遵循简洁原则，在集中管理策略下实现了高效的本地通信机制，并成功避免了分布式设计带来的额外开销（1）、模块化开发受限，在技术选型上受到严格限制（2）、各模块之间高度依赖导致系统整体稳定性较低（3）、无法快速响应需求变化（4）、集群计算资源消耗高
随着业务规模的不断扩大以及系统复杂性的提升（1）、系统必须基于单一技术框架以确保稳定性和可维护性（2）、各模块之间的高度依赖导致系统整体稳定性较低（3）、无法快速响应需求变化（4）
垂直拆分：在业务扩展的过程中，默认选择垂直方向进行拆分以提高复用率并降低维护成本
优点：将业务进行垂直拆分以实现模块独立；系统独立部署与维护策略；每个模块在自身运行环境中独立运作；通过分散管理降低整体复杂度；缺点：拆分程度增加可能导致存储资源消耗上升；系统间的数据交换可能导致更多的数据冗余；单个系统的模组化程度有限；分布式服务由于现代业务系统的规模不断扩大以及设计复杂度的提升，在传统架构难以应对的情况下，在遵循"不要分布式"的原则下,"分布式"时代就这样应运而生
优点：
1、独立进程部署，独立进程运行，独立演化。服务之间可以做到高内聚，低耦合。 2、独立开发和维护，业务解耦，无论是业务系统还是分布式服务都独立演化。 3、分布式管理 4、隔离性增强 5、由一系列服务组装成系统，不用重复建设，模块、代码可以复用。 缺点： 1、数据一致性（多服务完成一个任务）和系统的可用性（集群）成为问题 2、数据库也进行了拆分。 3、维护、设计、架构成本增加，调试、纠错更难。 4、网络传输分布式损耗成本 5、不适合高并发和大数据的环境。 4、微服务架构 微服务的出现时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的解决方案，对于现在的业务系统来说，分布式架构已经变成了一种常规手段，这个时候，微服务就出现了。微服务架构是一个用分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的一种，是在分布式技术成熟之后，然后把分布式当成解耦手段来架构系统-----因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩小了，由以前几个大的服务，转变为多个独立运行的、原子性质的服务。 如图：
微服务的核心特点包括以下几个方面： （1）可用性：它定义了一个系统在运行期间提供有用资源的能力，并通过减少停机时间来保障服务的整体可靠性。（2）弹性：基于需求动态配置系统中的资源数量的能力，在水平方向上扩展称为横向伸缩，在垂直方向上提升性能称为纵向伸缩。通过负载均衡技术实现系统的高可用性和弹性扩展。其优势主要体现在以下几个方面： （1）支持使用多种语言或同一语言的不同版本开发各个功能模块。（2）采用 loose coupling 原则使各子系统之间相互独立、互不干扰。（3）能够快速响应市场变化的需求并适应敏捷开发模式。（4）根据不同子系统的具体情况灵活应用集群策略以解决问题。然而该方案也存在一些局限性： （1）相比传统架构其复杂度更高导致开发周期更长。（2）通信开销大会影响整体性能表现。基于 service-oriented architecture 的解决方案 Service-Oriented Architecture SOA 是一种组件化的架构模式它将应用程序的功能分解为多个独立的服务并通过明确定义的服务间接口和协议实现了各服务之间的协调与协作如图所示
三、微服务架构的发展历程 在解决微服务高可用性和可扩展性的问题时，默认会想到采用集群模式来实现这一思路是正确的。一旦实现了集群功能，则会衍生出另外两个问题：如何发现新服务以及如何检测现有服务实例是否出现故障（如掉线）。这些问题的解决直接关系到微服务架构的发展阶段划分。第一个关键问题是关于服务发现机制的设计：调用方如何通过某种方式发现新增的服务实例，并能及时察觉现有服务是否出现故障（如实例掉线）。如果无法有效解决第一个问题，则第二个关于多集群实例间服务调用管理的问题就无法得到妥善处理；第二个关键问题是关于多实例管理：当存在多个集群实例时（即多个服务实例），如何组织这些实例以便于调用，并明确各服务之间的交互关系？这些问题的存在促使我们深入探讨微服务架构的发展版本解决方案。1、集中式代理模式——Nginx（V1.0 版本：基于手动配置的服务注册与发现机制）
(1) 实现自动化配置管理, 通过手动操作完成配置调整后即可正常运行。(2) 在分布式系统中, 负载均衡可以通过轮换训练不同的节点来保证公平分配资源; 同时支持根据业务需求设置节点权重以及基于哈希值进行负载分配。(3) 在新集群成员加入时, 系统无法立即识别其身份; 因此在新成员上线前必须执行必要的配置工作；当集群成员出现在线异常情况时系统会自动触发排查机制。(4) 客户端开发过程较为简单, 在功能实现上无需额外编写代码即可达到预期效果。(5) 客户端嵌入方案采用Consul架构设计,V2.0版本主要包含动态注册与自适应负载均衡等功能模块
（1）、服务注册与发现按照需求按需扩展，并能自主完成流程。（2）、健康检查能够检测当前运行状态并能及时移除不再运行的服务实例, 系统会自动处理相关流程。（3）、负载均衡方面, Consul 返回所有活动服务实例信息, 但目前主要由客户端自行负责实现, 功能上非常强大但集成较为复杂。（4）、Service Mesh（V3.0）技术尚处于初期阶段, 由华为联合唯品会推出, 并采用lstio方案进行支持。
侧car业务中的侧car实例定位与识别, 对侧car实例进行管理和操作。side car业务中的side car管理方案由side car平台提供, side car平台负责管理所有side car。该技术我不多谈了, 网上的资料也很多, 目前该技术还不够成熟, 使用范围也不够广泛, 只是被一些大型企业采用过, 比如:微软等公司
四、微服务架构必备技术栈
微服务是一种软件设计与架构思想，在其中也包含了许多相关技术点以解决当前问题。深入学习微服务并非空谈而是要落实到具体的技术架构上。目前应用较为广泛的有两种技术体系一个是Java另一个是Net现役人员我主要使用微软相关的技术架构人员身份同时也是采用微软技术栈进行微服务架构的设计今天将详细列出所涉及的技术点1 微服务架构中的关键技术包括WebService WCF WebAPI等微软自身的技术体系此外还可以使用ASHX ASPX等技术这些都是微软特有的设计成果无需赘述（1）主动触发机制（2）数据序列化传输（3）跨平台支持（4）跨语言能力（5）防火墙穿透能力2 微服务架构中的进程通信机制（1）Net Remoting仅限于Net平台不支持跨平台操作（2）gRPC一种高性能开源通用的RPC框架基于HTTP/2设计适用于服务器端及移动端具备推荐使用性3 微服务架构中的API网关服务功能由Ocelot提供支持
API网关——它是系统面向外部的一个入口点。它类似于门卫角色的组件，在职责上承担着地址转换、权限控制、身份验证、位置指引等功能等多方面的任务。Ocelot是一个基于.NET Core开发并开源的API网关工具软件包，在功能上集成了：路由管理、请求批次处理能力以及服务定位等功能，并且内置了负载均衡策略与Service Fabric组件支持，并结合Butterfly Tracing技术实现全栈追踪功能。这些功能模块只需通过简单的配置即可实现相应的功能部署与优化效果展示效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果表现效果显著的效果
官方网站链接：此处可点击访问，属于微服务架构体系中的认证模块与权限管理。
如今应用开发呈现出多样化与丰富性
IdentityServer4属于这一类别的系统，在设计上专为ASP.NET CORE而生，并且支持了OpenId Connect和OAuth2.0协议的功能。
项目网站：https://github.com/IdentityServer/IdentityServer4；微服务架构 — 瞬态故障处理
Polly是一款强大的类库。
Polly是一种基于.NET的弹性与瞬态故障处理库。
通过提供诸如断路、超时、故障恢复等策略的支持，我们可以实现高效的业务流程管理。
该库支持 .NET 4.0、4.5、Standard 1.1以及 Core 框架。
该项目作者现已成为.NET基金会一员。
项目持续进行迭代优化与更新维护。
你值得拥有。
项目地址：<https://github.com/App-vNext/P Polly>
6、微服务架构----分布式追踪
伴随着微服务架构的兴起，在这些架构下出现的问题往往会愈发突出。例如一个请求往往牵扯到多个不同的服务这些服务可能会相互依赖地连接在一起形成一个复杂的交互网络A service request typically forms a web-like structure of interactions.在这样的网络中如果任何一个节点出现问题整个系统的稳定性都会受到严重影响The term 'silver bullet' is increasingly recognized as nonexistent.A silver bullet is increasingly recognized as nonexistent.每一种架构都有其自身的优缺点
针对当前出现的问题
通常情况下，在大多数情况下我们都需要进行日志分析这一场景：直接通过使用grep命令和awk脚本可以在日志文件中快速提取所需信息。然而，在数据量庞大且情况较为复杂的情况下（即所谓的规模较大或复杂场景），该方法的效率会显著降低，并面临以下问题：如何应对日志总量过大导致的存储压力？如何解决文本搜索速度较慢的问题？以及如何实现多维度的数据查询需求？因此需要一种更加集中的日志管理系统来整合所有服务器上的日志数据并实现统一管理和高效访问。常见的解决方案是建立一个集中式的日志收集与管理系统，在各个节点设备上统一部署相关采集与处理功能，并通过该系统整合并管理所有的原始 logs 数据源以提高整体的日志处理效率和可管理性
一般情况下,大型系统的架构采用分布化部署方案,各个服务模块被分别部署在独立的服务器上.当问题发生时,在多数情况下需要依据暴露的问题关键信息点来识别出具体的服务器以及相关服务模块,并配置一套集中式日志收集与分析平台,显著提升了故障定位效率
该开源项目Exceptionless提供了一个实时的日志收集解决方案，并支持多种技术架构包括 ASP.NET、ASP.NET Core、Web API、Web Forms、WPF、Console以及MVC等主流开发框架。此外该工具还提供了RESTful接口使其不仅适用于JavaScript也能够很好地支持Node.js环境下的开发需求。通过Exceptionless日志收集模块能够简化日志管理和配置操作无需深入掌握复杂的系统细节或配置参数即可实现高效稳定的工作状态。相比之下传统的Log4net和Nlog等框架虽然功能强大但随着应用程序复杂性和集群化的发展它们已无法满足日益增长的日志管理需求因此传统的日志收集方式在这种情况下可能会导致管理过程繁琐且耗时效率低下
如今Exceptionless团队为我们呈现了一个更为卓越的解决方案来完成这项工作。我认为这一创新成果意义重大且价值非凡，并深感感激。
GitHub repository：https://github.com/exceptionless/Exceptionless
（2）、ELK代表三个开源软件的具体项目：Elasticsearch、Logstash和Kibana这三个都是开源软件项目。然而，在此基础上又增添了一个Beats模块——这是一个轻量化的日志收集与处理模块（Agent），并且其占用资源较少，在各个服务器上都能够方便地从其收集并传递日志信息给Logstash系统，并获得官方推荐支持。值得注意的是，在原先ELK组件集合中引入了Beats这一模块之后已重新整合成为新的Elastic Stack架构结构。建议优先考虑采用该方案
8、微服务架构----分布式配置中心
Apollo是由携程框架部门开发的一款综合管理平台，在整合各环境下的配置资源方面具有显著优势，并能实时同步至应用端；该平台不仅支持自动同步至应用端，并且确保了操作规范性和流程完整性。
该服务端采用 Spring Boot 和 Spring Cloud 技术实现开发，并通过打包方式直接运行；无需额外安装 Tomcat 等应用容器即可直接运行。
Java客户端无需依赖任何框架，并可在所有 Java 运行时环境中运行；同时对 Spring 环境也具有良好的兼容性
基于 .NET 的客户端无需依赖任何框架，在所有 .NET 运行时环境中都能顺利运行。 项目地址：GitHub - apolloconfig/apollo: Apollo 是一个可靠的一键式配置管理解决方案...
9、微服务架构----分布式锁 分布式锁的具体解决方案有很多种，在这里我将列举其中一些，并计划在未来通过实践来实现这些技术点。
（1）、Consul 可以实现分布式锁 （2）、Redis 可以实现分布式锁并推荐使用。（3）、Zookeeper 可以实现分布式锁 （4）、数据库 可以实现分布式锁。
10、微服务架构----分布式事务 分布式事务的具体实现方式也不少，在未来的时间里我会继续努力去掌握这些知识。
（1）、2PC（two-phase commit protocol）是一种强一致性协议但不具备可用性。（2）、3PC 是另一种协议。（3）、TCC（Try-Confirm-Cancel）是一种容错协议。（4）、本地消息表是RabbitMQ推荐的一种具体实施方式。（5）、Saga模式是基于本地消息表的一种分布式的事务管理方案。
（1）上有投递消息 （2）下游获取消息 （3）上游投递稳定性 （4）下游接受稳定性
11、微服务架构—容器化技术 在实际应用中如何选择合适的容器化工具和技术方案是一个需要深入研究的问题。
Docker 是一个开放源代码的应用容器引擎,能够将应用程序及其所需的依赖项集成到一个可移植的镜像中,并部署至 variety of Linux distributions and Windows operating systems, 同时支持虚拟化部署.
采用客户端-服务器架构模式的 Docker 应用系统采用了远程API实现了对Docker容器的管理与创建过程
基于C/S架构和Docker daemon充当服务端来接收并处理客户请求（创建新容器、启动现有容器以及将资源分配给容器）
通常位于宿主主机的后台运行，并持续接收客户端发出的消息请求。 Docker 客户端则提供了一系列可以执行的命令指令，并由用户通过这些命令与 Docker daemon 进行交互操作。
如图：
12、微服务架构—容器编排
Kubernetes是一个源自Google开源的容器编排引擎，在支持自动化的部署能力的同时具备按需扩展的特点，并能够实现对应用进行微服务化管理。一般情况下会为在生产环境中运行的应用程序预先部署多个实例，并且为了实现负载均衡的目的，在生产环境中需要为每个应用程序预先部署多个实例。
在Kubernetes环境中, 我们可以部署多个容器, 在每个容器内运行一个独立的应用实例. 基于内置的负载均衡机制, 实现对这组应用实例的动态管理和状态监控, 并提供访问路径. 此外, 无需运维人员进行复杂的手动配置或繁琐的操作.
Kubernetes 可被视为 Docker 的容器编排工具。它旨在管理应用程序的整个生命周期，并能从部署及服务提供过程均能带来便利性。此外，在应用数量变化时可实现自动扩缩容，在应用更新需求时同样支持及时响应。系统故障发生后会自动切换至可用节点以保障服务稳定运行。
中文社区：Kubernetes(K8S)中文文档_Kubernetes中文社区
官网：https://kubernetes.io/docs/home/13、微服务架构—CI/CD
Jenkins 是一个基于开放源代码理念开发的应用程序集成工具，在软件开发中具有重要地位。它通过友好的人机交互界面让用户能够方便地配置和管理构建与测试流程，并具备自动化管理的能力来监控外部任务的状态变化。
官方网站: Jenkins中文站 - 免费开源的持续集成解决方案、Jenkins安装指南、Jenkins操作手册及培训课程
五、 结束语
到这里为止吧？反正今天确实做了不少事情呢！除此之外嘛，则是主要为了记录所涉及的技术栈及相关内容啦！如果有机会的话，则会对每一项技术都进行了深入的研究和学习；但也有可能选择一个项目来进行深入研究哦！毕竟这个项目中可能会涉及许多其他相关技术和知识点嘛！具体情况如何安排后续的研究方向，则视情况而定啦！只要每天都能进步一点的话，则会继续努力哦！