2023年7月17日发(作者：)

微服务及技术栈介绍简介这些年软件的设计规模越来越庞⼤，业务需求也越来越复杂，针对系统的性能、⾼吞吐率、⾼稳定性、⾼扩展等特性提出了更⾼的要求。可以说业务需求是软件架构能⼒的第⼀推动⼒，由于这些因素导致了软件架构思想和相关技术也在发⽣着巨变。这些变化反应在软件架构⾏业⾥，就是我们开始越来越多的听到了很多新的词汇，⽐如：“分布式”、“SOA”、“微服务”、“中台”等概念。今天我就把我学习微服务的过程记录下来，包括所有技术的实现细节和个⼈的理解。俗话说：好记性，不如烂笔头，以防⾃⼰忘记，以后可以查询。当然，这些东西有很多东西都是⾃⼰的理解，⾥⾯的插图也是⾃⼰画的，可能会有⼀些有失偏颇的地⽅，当然希望有⾼⼿可以指正，不灵赐教，⼤家共同进步。架构发展历程现在的科学技术可以说是⽇新⽉异，发展迅速。相对于我们软件设计⾏业也在发⽣着巨变，业务越来越复杂，需求越来越庞⼤、繁杂，软件架构和部署的规模也发⽣着翻天覆地的变化，作为软件架构思想之⼀的“微服务架构”也在按着⾃⼰的规律进化着，接下来我们就简单的了解⼀下“微服务架构”发展经历的三个时期，这些只是个⼈理解。单体架构（Monolithic）单体应⽤时代：应⽤程序⽆论如何分层，都是⼀个解决⽅案，或者说都是⼀个项⽬，这⾥的“解决⽅案”和“项⽬”不是我们使⽤的Visual Studio⾥⾯的概念，最终的程序代码都会在⼀个进程⾥运⾏。如图：优点：开发简单，集中管理，没有分布式的损耗，都是系统进程内的通信。缺点：不好维护，升级困难，耦合严重，⽆法应付⾼并发和⼤数据场景，⽆法快捷迭代。•只能采⽤同⼀种技术，很难⽤不同的语⾔或者相同语⾔不同版本开发不同模块。•系统耦合性太强，其中⼀个模块有问题，这个系统就会瘫痪，⼀个模块升级，整个系统就得停机维护。•要上线，必须⼀起上线，互相等待，⽆法快速相应市场需求。•集群负担⼤，如果想要集群，只能对整个系统进⾏集群，即使⼀个模块有压⼒。垂直拆分随着业务规模的越来越庞⼤，系统设计就越来越复杂，⼤的系统就开始进⾏业务的垂直拆分。⽐如：有专门做商品秒杀的部门，有专门做⽣鲜商品的部门，有专门做超市的部门，等等，当然这是根据部门天⽣划分的，也有根据业务需求进⾏系统划分的。如图：优点：垂直拆分，系统独⽴部署和维护，每个系统在⾃⼰进程内执⾏，分⽽治之。缺点：拆分越多，存储越复杂，系统间重复的东西也越多，单个系统还是单体模式。分布式服务随着业务系统的越来越庞⼤，软件系统设计起来越来越复杂。为了避免过度复杂的业务需求，开始对业务系统的进⾏垂直拆分，形成多个独⽴的业务系统，如果多个系统之间要通信，可以通过跨进程的技术完成通讯。但是垂直拆分也导致了⼤量重复代码、重复模块的产⽣，⽐如：⽤户模块、⽇志模块、⽀付模块、认证授权模块等，这样分散的代码也给系统的维护和升级带来了困难。我们对业务重新划分，把独⽴的模块接⼝化、服务化，提⾼重⽤，这个时候，我们就开始进⼊了分布式服务的时代。（分布式的第⼀要务就是不要分布式）如图：优点：•独⽴进程部署，独⽴进程运⾏，独⽴演化。服务之间可以做到⾼内聚，低耦合。•独⽴开发和维护，业务解耦，⽆论是业务系统还是分布式服务都独⽴演化。•分布式管理•隔离性增强•由⼀系列服务组装成系统，不⽤重复建设，模块、代码可以复⽤。缺点：•数据⼀致性（多服务完成⼀个任务）和系统的可⽤性（集群）成为问题•数据库也进⾏了拆分•维护、设计、架构成本增加，调试、纠错更难•⽹络传输分布式损耗成本•不适合⾼并发和⼤数据的环境微服务架构微服务的出现时分布式架构已经很成熟了，架构中各种问题已经有了很成熟的解决⽅案，对于现在的业务系统来说，分布式架构已经变成了⼀种常规⼿段，这个时候，微服务就出现了。微服务架构是⼀个⽤分布式服务拆分业务逻辑，完成解耦的架构模式（架构风格）。微服务肯定是分布式的⼀种，是在分布式技术成熟之后，然后把分布式当成解耦⼿段来架构系统——因为拆分的服务很细致，服务数量规模开始变多了，服务的体量开始缩⼩了，由以前⼏个⼤的服务，转变为多个独⽴运⾏的、原⼦性质的服务。如图：微服务最重要的特性是：•可⽤性：描述⼀个系统在⼀段时间内提供有⽤资源的能⼒，从⽽减少停⼯时间，⽽保持其服务的⾼度可⽤性。•伸缩性：根据需求动态添加和删除系统中资源的能⼒，是⽔平或垂直扩展的专门实现。集群（负载均衡）可以解决系统的⾼可⽤和伸缩特性。优点：•可以使⽤不同语⾔或者相同语⾔的不同版本开发各个模块。•系统耦合性低，各个模块分⽽治之，独⽴部署，独⽴发布，独⽴维护。•可以更快的相应市场的需求，更符合敏捷开发。•可以对不同模块使⽤集群策略，哪⾥有问题治哪⾥。缺点：•开发难度更⼤，系统结构更复杂。•运⾏效率低，⽹络调⽤成本很⼤。SOA⾯向服务架构Service-Oriented Architecture⾯向服务架构：是⼀个组件模型，它将应⽤程序的不同功能单元（称为服务）进⾏拆分，并通过这些服务之间定义良好的接⼝和协议联系起来。如图：微服务架构的发展历程我们要解决微服务的⾼可⽤和可伸缩的两个问题，⾃然就会想到通过集群来实现，这个思路没有错。如果我们实现了服务集群，那另外两个问题就会出现，这两个问题也导致了微服务架构的发展版本的差异。第⼀个：服务的发现问题，调⽤⽅如何发现服务，有了新的服务，我们如何知道，有服务实例掉线，我们如何晓得，发现服务就很重要，这个是基础问题，第⼀个问题不解决，第⼆个问题也没有办法实现；第⼆个：如何调⽤服务，如何管理那么多的服务实例。有那么多的集群实例，也就有那么多的服务实例，我们该怎么去调⽤这些服务呢？多个服务调⽤的关系如何呢？由于这些问题，那我们就看看微服务架构的三个版本是如何解决的。集中式代理——Nginx V1.0版本（服务注册/服务发现——⼿动）•服务发现，⼿动修改配置⽂件，重新启动。•负载均衡，可以轮训、权重、哈希等等。•服务新增⽆法发现，需要⼿动配置，服务掉线可以⾃动检查。•客户端的实现很简单，不需要额外的代码，简单，⾼效。•客户端的实现很简单，不需要额外的代码，简单，⾼效。客户端嵌⼊——Consul V2.0版本（服务注册/服务发现——⾃动——服务治理）•服务注册与发现，动态增加，⾃动完成。•健康检查，可以查看损坏服务，去掉服务，⾃动完成。•负载均衡，Consul返回所有活动服务实例，客户端⾃⼰实现负载均衡。功能强⼤，⾃动发现-⾃动下线，客户端集成⽐较复杂，负载均衡在客户端实现。服务⽹格——Service Mesh V3.0——技术不成熟，华为+唯品会，IstioSideCar服务管理服务实例的注册和发现，服务实例的治理和调⽤。Service Mesh’s Control Plan管理所有的SideCar。这个技术我就不多谈了，⽹上的资料也很多，⽬前这个技术还不是很成熟，使⽤的范围也不是很⼴，只有⼀些⼤的公司有过使⽤，⽐如：微软等。微服务架构必备技术栈微服务是⼀种软件设计、架构思想，当然，⾥⾯也包含了相关技术点要解决当前要务。学习微服务，我们不能空⼝⽽谈，⼀定要落实到具体的技术栈上。当今使⽤⽐较多两个技术体系，⼀个是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是为 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是⼀个开源的实时的⽇志收集框架，它可以应⽤在基于， Core，Web Api，WebForms，WPF，Console，MVC等技术栈的应⽤程序中，并且提供了Rest接⼝可以应⽤在Java，中。它将⽇志收集变得简单易⽤并且不需要了解太多的相关技术细节及配置。在以前，我们做⽇志收集⼤多使⽤Log4net，Nlog等框架，在应⽤程序变得复杂并且集群的时候，可能传统的⽅式已经不是很好的适⽤了，因为收集各个⽇志并且分析他们将变得⿇烦⽽且浪费时间。现在Exceptionless团队给我们提供了⼀个更好的框架来做这件事情，我认为这是⾮常伟⼤并且有意义的，感谢他们。ELK是三个开源软件的缩写，分别为：Elasticsearch、Logstash以及Kibana，它们都是开源软件。不过现在还新增了⼀个Beats，它是⼀个轻量级的⽇志收集处理⼯具（Agent），Beats占⽤资源少，适合于在各个服务器上搜集⽇志后传输给Logstash，官⽅也推荐此⼯具，⽬前由于原本的ELK Stack成员中加⼊了Beats⼯具所以已改名为Elastic Stack。推荐给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/CDJenkins是⼀个开源的、提供友好操作界⾯的持续集成（CI）⼯具，主要⽤于持续、⾃动的构建/测试软件项⽬、监控外部任务的运⾏。结束语好了，今天就写到这⾥了，没别的，就是做⼀下相关技术栈的记录，以后有时间，再把每项技术仔细研究，可能是每项技术，也可能是以⼀个项⽬来研究，这个项⽬中可能包含很多其他的技术，到时候，再决定。每天进步⼀点，加油。