微服务的简介和技术栈
一、简介
这些年软件的设计规模越来越庞大，业务需求也越来越复杂，针对系统的性能、高吞吐率、高稳定性、高扩展等特性提出了更高的要求。可以说业务需求是软件架构能力的第一推动力，由于这些因素导致了软件架构思想和相关技术也在发生着巨变。这些变化反应在软件架构行业里，就是我们开始越来越多的听到了很多新的词汇，比如：“分布式”、“SOA”、“微服务”、“中台”等概念。
今天我就把我学习微服务的过程记录下来，包括所有技术的实现细节和个人的理解。俗话说：好记性，不如烂笔头，以防自己忘记，以后可以查询。当然，这些东西有很多东西都是自己的理解，里面的插图也是自己画的，可能会有一些有失偏颇的地方，当然希望有高手可以指正，不灵赐教，大家共同进步。
当前科技领域正经历着飞速发展，在这一背景下我们也面临着巨大的变革与挑战。软件设计行业正在经历深刻转型，在这一过程中业务趋于日益复杂化的同时需求也呈现出日益繁重的特点。伴随着这些变化软件架构与部署规模也经历了翻天覆地的变化作为软件设计思想的重要组成部分"微服务架构"也在按照其自身的发展规律逐步演进接下来我们将重点介绍"微服务架构"发展的三大历史阶段这只是个人的一点见解。
1**、单体架构（Monolithic）**
单一架构时代的应用：不管如何进行模块划分的应用程序都可被视为一个整体方案或简单地看作是一个系统工程。这里的"解决方案"和"项目"并不是我们通常在Visual Studio中所理解的概念，在这种架构下，整个程序的执行过程通常在一个独立的进程中完成。
优点：开发过程较为简单；管理集中且高效；采用了免除了分布式架构的潜在问题的设计；采用了统一的通信机制以保证系统的稳定运行。 缺点：维护难度较大；升级过程复杂且耗时较长；各模块之间高度依赖关系导致系统稳定性受限；在高并发和大数据环境下表现不佳；迭代速度较慢。（1）、项目团队只能选择单一技术路线，在技术选型上存在较多限制。（2）、系统各模块间高度耦合，在设计上存在较强的制约关系。（3）、上线时需同步进行互操作性测试，并确保所有子系统的协同运行。（4）、构建集群需要对整个系统进行配置并承担相应的性能压力
2、垂直拆分
优点：垂直方向上的分解采用了分散管理策略，在各个子系统的运行中实现了完全独立的部署与维护工作。每个子系统分别在各自的任务范围内运行以避免相互干扰。缺点：随着拆分数目增加存储结构会随之变得更为复杂这将导致不同系统的交互内容也会显著增加同时每个子系统的规模仍需维持相对独立的架构以保证整体性能的稳定性和可扩展性。
随着业务系统的规模不断扩大, 软件系统设计的复杂程度日益增加。面对过于复杂的业务需求, 开始将业务系统按照垂直方向进行拆分, 形成若干个相互独立的子系统; 若这些子系统之间需要进行通信, 可通过跨进程机制实现通信过程; 但这种垂直拆分的方式会导致大量重复代码片段的存在, 从而产生许多非必要的功能模块, 如用户管理模块、日志管理模块、支付处理模块以及认证与授权管理模块等; 这样的分散化导致在维护与升级过程中会面临诸多挑战; 我们采取了一种新的划分策略: 将各个独立的功能单元进行接口化设计, 并赋予其服务化的特性; 以提高重用能力为目标; （分布式的核心理念在于消除'分布'这一概念）
优点：
采用独立进程部署策略，在运行过程中实现了高内聚和低耦合；通过独立开发与维护实现业务解耦；系统采用分布式管理架构；该方法显著提升了系统的隔离性；该系统由多个模块化服务组成，并具有良好的代码复用性
4、微服务架构
如图：
微服务体系的关键特征在于其卓越的可用性和可扩展性。具体而言：
（1）可用性方面：系统在特定时间段内持续提供必要资源的能力。
（2）可扩展性方面：基于实时负载状况动态调整计算资源数量的能力。
此外，在集群架构下采用负载均衡技术可以有效实现系统高可用性和弹性扩展的目标。
优点：
****（1）、可以使用不同语言或者相同语言的不同版本开发各个模块。
****（2）、系统耦合性低，各个模块分而治之，独立部署，独立发布，独立维护。
****（3）、可以更快的相应市场的需求，更符合敏捷开发。
****（4）、可以对不同模块使用集群策略，哪里有问题治哪里。
缺点：
****（1）、开发难度更大，系统结构更复杂。
（2）、运行效率低，网络调用成本很大。 5、SOA 面向服务架构
Service-Oriented Architecture 面向服务架构：是一个组件模型，它将应用程序的不同功能单元（称为服务）进行拆分，并通过这些服务之间定义良好的接口和协议联系起来。
如图：
三、微服务架构的发展历程
为了解决微服务体系中高可用性和可扩展性的问题,我们自然会考虑到采用集群架构这一思路,这个方向是正确的。一旦实现了集群功能,其他相关问题也随之出现,这些现象推动了微服务架构的发展阶段划分。第一个核心问题是:当新服务加入时,如何帮助调用方发现现有服务的状态？具体来说,包括发现新服务、检测服务实例故障以及识别服务失效等情况,这些问题的解决是基础性的前提条件;第二个核心问题是:在面对大量集群实例时,如何实现对这些服务实例的有效管理与调用？多个独立的服务实例之间如何建立调用关系？这些问题的存在促使我们需要深入探索解决方案。基于此背景,我们就需要研究微服务架构的三个发展版本是如何应对这些挑战的
1**、集中式代理----Nginx（V1.0 版本（服务注册/服务发现----手动））**
（1）、通过"服务识别"机制完成发现功能后，请您完成"手动配置文件修改"操作并重启相关服务。
（2）、在"负载均衡控制"方面支持采用"轮询"策略、动态分配"权重"以及基于"哈希算法"进行资源分配等多种方式。
（3）、新增的服务未被检测到，则仍需进行手动配置设置；当出现断线情况时会自动进行检查。
（4）、客户端实现过程非常简单，并且无需编写额外代码即可完成功能；整个流程具有极高的效率和可靠性。
2**、客户端嵌入----Consul（V2.0版本（服务注册/服务发现—自动---服务治理））**
（1）、支持动态扩展的注册与发现机制。
（2）、健康检查功能可实时监控并评估各服务的状态，在必要时及时移除已损坏的服务。
（3）、该系统会收集并返回所有运行中的活动服务实例，并将负载均衡的任务交由客户端进行管理。
功能性能突出，并实现了自动生成部署和关闭机制；但客户端的集成过程较为繁琐；此外，在客户端实现了负载均衡的分配
3**、服务网格-Service Mesh（V3.0---技术不成熟，华为+唯品会，lstio）**
SideCar服务管理服务实例的注册与发现功能以及服务实例的治理与调用方案均被包含在内。该方案负责管理所有SideCar服务实例。然而该技术目前还处于发展阶段，并未得到广泛的应用。相关资源较为丰富但该技术尚未完全成熟化，并且应用领域较为局限目前仅有少数大公司进行尝试包括微软等企业
四、微服务架构必备技术栈
微服务是一种软件设计、架构思想，当然，里面也包含了相关技术点要解决当前要务。学习微服务，我们不能空口而谈，一定要落实到具体的技术栈上。当今使用比较多两个技术体系，一个是Java，另外一个就是Net，废话不多说，我是使用微软相关技术栈的软件架构人员，当然使用的“微服务”架构技术栈也都是微软的。今天我就把相关“微服务架构”所用到的技术栈罗列出来，我也要说明一下，微服务架构里面的很多技术是和开发语言无关的 ，无论是 .Net 还是 Java 平台都可以使用。以后，一步一步的针对每项技术在做深入研究。
1**、微服务架构----服务通信**
WebService、WCF、WebAPI，甚至可以是 ASHX,ASPX，这都是微软本身的技术体系，没什么可说的。
（1）、主动触发
（2）、数据序列化传递
（3）、跨平台。
（4）、跨语言
（5）、Http 穿透防火墙。
2、微服务架构----进程通信
（1）、Net Remoting：该平台用于进程间的管理与对接，并且不具备跨平台功能。
******（2）、gRPC：基于 HTTP/2 的高性能、开源且通用的 RPC 框架，在服务端与移动端均有良好表现并设计精良，
建议采用这一解决方案以实现高效的通信需求。
3、微服务架构---API网关服务（Ocelot）
API网关—— 它是系统面向外部的一个入口点。它类似于一个代理服务器角色，在接收外部请求时执行身份验证、权限控制以及负载均衡等功能。Ocelot是一款基于.NET Core开发的开源API网关工具软件，在配置上非常便捷：它不仅支持基本功能如路由管理、限流与熔断等核心组件的配置（包含负载均衡器与Service Fabric集成），还可以通过扩展包进一步添加.Butterfly Tracing追踪功能以满足复杂场景需求
官网：https://ocelot.readthedocs.io/en/latest/index.html
4**、微服务架构—认证 &授权**
目前的应用开发呈现出多样化的发展态势，在线服务、移动互联以及云计算等领域相互交叉融合形成了众多创新性应用场景。具体而言，在现有技术架构下主要包含以下几个维度的应用类型：基于浏览器技术的网站应用、基于微信生态的小程序与公众号、移动端应用（iOS与Android平台）、桌面类软件及Windows平台上的 Universal Windows Platform（UWP）应用程序等。在实现各类独立功能模块的同时需要考虑不同场景间的交互关联关系，并在此基础上提炼出通用功能组件以满足多场景协同运行的需求。其中身份验证与权限控制作为各类系统的核心安全机制在整个系统架构设计中占据重要地位。随着互联网技术的快速发展与安全性需求日益提升统一的身份认证与权限管理解决方案显得尤为关键。
这个框架正是专为打造的一个综合性的身份认证与授权解决方案；它特别针对ASP.NET CORE进行了定制开发，并且内置了OpenId Connect和OAuth2.0协议的支持。
项目地址：https://github.com/IdentityServer/IdentityServer4
5**、微服务架构—瞬态故障处理**
这是一个功能丰富的.NET类库工具包Polly它集成了弹性设计与快速恢复机制支持各种场景下的异常处理方案包括重试机制断路复连超时监控以及故障自动修复能力。Polly经过多次升级优化现已成为 .NET 开发社区的重要组件其版本涵盖.NET 4.0至.NET Core 2.1平台并且得到了.NET基金会的认可与认可。作为持续优化中的一项重要成果Polly不仅提升了项目的稳定性和可靠性也为开发者提供了更加便捷的技术支持。
该项目地址位于GitHub仓库App-vNext/Polly仓库中您可以访问并了解更多信息。
项目地址：https://github.com/App-vNext/Polly
6**、微服务架构----分布式追踪**
在微服务架构的大背景下，在线部署和运维的压力下会出现的问题逐渐凸显出来。例如，在一个请求中通常会同时调用多个不同的组件或服务，并且这些被调用的服务又可能会间接依赖其他组件或模块。这样一来，在整个系统的运行过程中就会形成一条错综复杂的调用网络结构。当任何一个环节出现问题时（例如某个核心组件出现性能瓶颈或者响应超时），这条网络结构的整体稳定性都会受到严重影响甚至崩溃。因此，在实际应用中我们很难完全做到完美无缺的设计目标
针对当前场景，
我们需要具备一些辅助分析系统行为的工具，
以便在出现故障时，
能够迅速定位并解决相关问题，
此时 APM（应用性能管理）工具正是 ideal 的选择。
项目地址：https://github.com/SkyAPM/SkyAPM-dotnet
7**、微服务架构----分布式日志**
在实际应用中处理日志分析场景时，默认情况下我们可以通过直接在日志文件中使用grep、awk等常见的Shell脚本工具来快速提取所需信息。然而，在面对日志规模大等情况时（比如单台服务器的日志量达到TB级），这种做法会导致效率低下并难以应对以下挑战：数据量庞大导致归档困难、文本搜索速度跟不上以及无法实现多维度的数据分析需求。为了实现对多源异构日志的高效管理和统一处理目标，在现有的基础设施支持下难以满足这些复杂需求。常见解决思路是通过建立集中式日志收集系统，在各个节点上部署统一的采集模块，并将其整合到统一的平台进行处理和管理。
大多数大型系统通常采用分布式架构设计。各个功能模块被独立分配至不同的服务器运行。当问题发生时,主要依据暴露的关键信息来确定具体是哪个服务器和功能模块。建立一套集中式日志收集与分析平台能够显著提升故障定位效率。
该开源工具Exceptionless提供实时的日志收集功能，并支持 ASP.NET、ASP.NET Core、Web Forms 等技术架构的应用程序设计。同时支持 RESTful接口开发，在JavaScript（如Node.js）环境中使用。其显著优势在于简化了日志管理流程，并非要求用户深入掌握相关技术和配置细节。过去我们做日志收集大多使用 Log4net 和 Nlog 等第三方日志管理工具，在应用程序变得复杂并且集群的时候（如部署到微服务或容器化环境），可能传统的方法已无法满足需求。因为过去常用Log4net和Nlog等第三方日志管理工具，在这些复杂的环境下可能会遇到性能问题或者集成困难的问题。而现在通过采用像Exceptionless这样的工具可以更高效地解决问题。现在的解决方案是通过提供更高效的API设计以及优化后的代码库来提升整体性能表现。
我们现在已经由Exceptionless团队为我们的工作提供了更高效的解决方案，并认为这一成果具有重要意义。
GitHub：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 运行时环境。
项目地址：https://github.com/ctripcorp/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 模式
本地消息数据库：MQ分布式事务—本地消息数据库—遵循一致性机制。
（1）上一层提交一条新消息
（2）接收方将收到新信息
（3）提供方的消息提交稳定性
（4）接收方的消息接收稳定性
11**、微服务架构—容器化**
Docker 是一个开源的应用程序容器引擎，在构建应用程序及其依赖项时提供了一个通用且可移植的应用程序运行环境。它允许将这些构建物部署到各种主流的 Linux 和 Windows 设备上，并通过虚拟化技术实现了资源的最佳利用和扩展性。
基于客户端/服务器（C/S）架构模式,Docker 使用远程API进行管理及生成 Docker 容器. Docker 容器基于 Docker 镜像构建. 如同面向对象编程中对象与类的关系,Docker 容器与 Docker 镜像存在对应关系.
Docker采用C/S架构中的Docker Daemon作为服务端接收客户发出的请求，并负责处理这些请求（创建、运行以及分配容器）。客户端与服务端不仅可以部署在同一台服务器上运行，也可以通过socket连接或者RESTful API进行通信。
Docker daemons通常处于后台运行状态，在响应客户端发出的通知时启动服务进程。Docker客户端则向用户呈现一系列可执行指令，在使用这些指令与 Docker daemons 进行交互时完成操作。
如图：
12**、微服务架构—容器编排**
Kubernetes作为Google开源的容器编排引擎，在支持自动化的部署方案的同时实现了资源的大规模扩展能力，并负责服务的容器化管理。当在一个生产环境中部署一个应用程序时,通常会配置多实例以实现对请求流量的有效分布
在Kubernetes环境中，我们能够部署多台容器，在每台容器内部运行独立的应用实例，并利用系统预设的负载均衡机制来实现对这些应用实例的有效管理和接入。这种自动化流程完全无需运维人员介入繁琐的手动配置工作。
Kubernetes也可视作Docker的应用容器调度器。它旨在管理和维护应用程序整个生命周期的状态与运行。从构建及部署、运行服务、容量调整、更新维护等关键环节来看,Kubernetes展现出极高的效率与可靠性，并能有效应对系统异常情况以保障业务连续性
中文社区：http://docs.kubernetes.org.cn/
官网：https://kubernetes.io/docs/home/
13**、微服务架构—CI/CD**
Jenkins 是一个开源的工具，具有友好的用户界面，并专注于自动构建和测试软件项目。它通过实时监控外部任务的状态变化来确保系统的稳定运行。
官网: http://www.jenkins.org.cn/
五、 结束语
到这里为止吧！今天的工作量还挺大的呢！没有其他的事情了。主要是记录下目前使用的技术栈和技术细节。等有机会的时候再深入研究每一个技术细节或者作为一个整体项目来分析和探讨它们之间的关联性吧！毕竟一个项目可能会涉及较多相关技术和细节嘛！每天进步一点吧！继续努力吧！