微服务架构简介一、微服务架构的诞生背景在互联网早期，也就是Web1.0时代，当时流行单体应用，研发团队比较小，主要是外部网页，然后是新闻门户等；在新世纪的互联网时代，即Web2.0时代，网民数量激增，电子商务、社交等巨头级互联网产品相继出现，流量和业务复杂性与上一个时代相比有了质的变化。这时候一个场景有几百甚至上千的研发团队，单一服务的研发效率等劣势就显现出来了。这时候出现了一种叫做SOA的架构。它的架构思想和微服务非常相似。它还具有类似于ESB的集中式组件。阿里的HSF，包括后来开源的Double，就是在这个阶段诞生的。移动互联网时代出现后，各种APP出现，生活开始全面互联网化。高流量、高并发、大规模的研发团队越来越普遍，相应地，对高科技生产力的要求也逐渐提高，微服务的概念应运而生。微服务其实已经贯穿了整个架构的发展。在Java技术栈中，SpringCloud、Double等框架已经非常流行。不难发现，整个社会已经进入数字化高速发展阶段。这时候涉及到更大的问题，比如流量增加，整个应用的复杂度增加，研发团队扩大，对效率的要求更高。2.单体时代1.0版本的大部分公司或者早期业务都会经历这样一个过程。起初，它是一个客户。这时候访问需要经过一个入口。上图中的SLB是阿里云的负载均衡服务。相当于一个网络入口，可以对应ECS（ECS是阿里云的虚拟机），进入对应的单体服务。这时候，他们会共享一个数据库。这是第一期。3、从单体时期的2.0版本到二期的SOA架构，带来了分而治之的思想，会拆分一些业务。但是此时还没有实现服务和底层的分离，比如存储数据库的拆分，本质上还是共享一套数据库，所以还是单体架构。4、微服务期在微服务期，如果客户端通过SLB访问一个网关（如图），会转发到对应的服务，服务与服务之间会产生一些调用。每个服务对应一个单独的数据库或缓存，每个服务通过类似Nacos的服务进行注册发现和配置管理。引入微服务后，虽然解决了架构和业务的分离，但研发团队可以专攻某个领域和业务。但是从整体架构上来看，会发现其实比以前更复杂了，所以也带来了一些运维方面的问题。在单体架构中，对于单体应用，会存在边界不清、模块耦合、共享代码库冲突等问题。同时，如果团队规模较大，此时协作效率会比较低。但是微服务架构的核心是解耦。如果实现拆分后的解耦，可以释放开发团队的效率。云原生时代微服务架构的发展1、云原生时代将微服务技术引入云原生技术是一个非常宏观的概念。帮助我们更好地理解什么是云原生。微服务和整体应用程序的本质是什么？如图所示，它实际上是将一个单体应用从一个巨型应用拆分成若干个微小的服务，然后协同完成与原单体应用等价的业务服务。这时微服务与微服务之间就会形成依赖关系，所以可能需要部署到一个或多个资源上，而此时的资源就是计算资源。过去单体应用与资源的关系非常简单，单体应用之间的协作都是内部协作，没有外部动态依赖。架构转为微服务后，由于外部依赖和节点数量的激增，整个系统会变成一个网络，管理起来非常复杂。超过50%的企业认为采用微服务架构最大的挑战是复杂的运维，即整个服务生命周期的管理。今天，人们普遍认为云原生的基础在于容器和容器管理编排（K8S）。容器和K8S技术可以帮助我们解决微服务系统中复杂的运维问题。首先，不同的微服务之间会存在异构性，也就是一个团队。为了最大限度地发挥微服务系统的效用，可能会允许不同的小团队使用不同的编程语言甚至不同的运行环境来运行这些微服务。.因此，我们在运维和管理这些微服务时，最初并没有一个统一的标准来应对这些异构环境。这也是后来云原生容器技术变得非常流行的原因，因为它的作用是通过一层标准化的封装和标准的运行时来限制微服务的部署。这样，从生命周期和管理的角度来看，各个微服务之间的差异就更少了，更有利于资源的调度。然后基于容器调度，衍生出一个容器平台。什么是容器平台？它实际上管理容器。对于K8S来说，它可以非常规范的在底层资源上运行微服务。那么存储计算网络可以通过K8S层进行统一封装，一层抽象封装，类似于云原生时代的操作系统。它具体有什么帮助？在K8S中，有一个概念叫做POD。POD其实就是一组容器的组合，再加上微服务实体的生命周期。在一个POD中，它可以运行一个或多个容器。在使用微服务架构时，微服务运行的主体一般都放在主容器中，即微服务执行的主要逻辑都放在主容器中。这时候主容器的生命周期就和POD的生命周期完全耦合了。的。即POD消亡，微服务的运行体消亡。另外，我们还会运行一些sidecar容器，也就是Sidecar，主要是为主容器提供一些辅助功能，比如日志收集，网络代理身份认证等，都可以放在Sidecar中。这样一来，微服务就有了超能力。除了提供自己的核心业务外，还可以动态提供额外的辅助能力，让微服务的管理更加健壮和便捷。此外，POD模型还提供了很多非常实用的功能。比如状态信息，状态信息的意思是：POD会提供一个标准的接口来显示运行时状态。通过这个信息状态，可以判断出整个微服务或者容器的运行状态。比如是否在运行，业务是否准备好接收流量接入，为整体的稳定性提供了保障。另一个是地址服务。地址服务是指每个POD都会有一个标准化的DNS地址服务。对于需要统一对外暴露的API非常有帮助，比如日志监控和追踪能力。通过DNS日志地址访问，或者一些暴露的可观察性信息，可以及时发现运行时问题。因此，我们可以看到，容器和容器平台可以帮助微服务在微观层面拥有更多的能力。图中展示了4种发布模式：1.滚动更新，2.固定更新。3.蓝绿部署4.金丝雀发布（灰度发布）流量管理微服务通过拆分将单体时代的静态通信关系转化为动态的运行时。服务之间的通信和协作通常需要单独管理，微服务框架帮助我们抽象和实现各个服务的公共功能。在抽象层面，包括业务逻辑与通信、流量、服务治理能力两个方面。我们可以在底层将一个通用的能力抽象成一个具体的框架，但是不同微服务之间的框架不能实现相互调用。但在云原生时代，可以使用不同的开发语言和模型进行编程，实现微服务的开发。ServiceMesh服务网格的出现就是为了解决多语言多环境下的流量管理问题。在数据层面，Sidecar负责流量劫持、转发和管理。这个功能的一个典型的sidecar实现是Envoy。如图所示，它会先从框架层面抽象出以上，然后直接和业务解耦，将通用的能力放在Sidecar中，通过Sidecar之间的通信转发进行管理；这会把问题简化很多。而我们只需要允许流量管理和sidecar通信，这时候不同技术栈的微服务实例就可以相互通信了。在管控层面，还需要一个组件来实现对原有微服务系统中策略规则的管理。经典的实现是Istio。总的来说，除了数据层面，我们还需要控制层面的支持。比如在原有的微服务体系中，服务注册、服务发现、流量观察等能力需要管控层面的主线来完成。我们可以通过管理POD中的流量和数据平面的单点，使它们形成一个网状结构，成为一个集群。此功能支持流量分配、安全性和观察。有了这些能力，它就形成了一个服务网格。图中的编程模型和函数计算相关的请求驱动是基于请求的动态弹性伸缩，简化了请求处理的逻辑。微服务调用，流量进来后，一般会经过四层或者七层负载均衡，然后分发到不同的微服务实例；但在同一个微服务实例进程内部，一般有两种逻辑。首先是请求管理，可能是一个HTTP服务器，或者是一些Handler，或者是一些队列管理，以及请求分发能力的组成。而这些组件最终会把这些请求提交给第二部分，也就是请求处理，而请求处理是开发者需要真正去实现的一些逻辑。比如JavaGo和Python都有自己的一套请求管理逻辑。然后是请求管理和请求处理之间的强耦合，包括请求管理和请求处理逻辑。在这种架构下，没有全局独立的控制层可以感知流量管理的请求。只有整个实例本身的处理层是这样解释请求的。即使此时微服务实例过载，也很难将这个请求转发给其他微服务实例进行负载均衡。所以请求驱动系统就是查数据和解决这两个要素，我们在做一个请求驱动的解耦。如图，首先从外部系统传来的请求会先被标准化，会有一个适配器，标准化后会放到请求负载均衡器中，负载均衡器可以理解请求的语义本身;然后它就可以被驱动和处理了。当处理单元不够时，可以通过manager进行扩容；当逻辑单元较多时，也可以缩减。这种转变变成了动态管理，可以为开发者节省大量的成本。请求驱动模型：?请求标准化?请求路由?处理管理请求标准化、请求路由和处理管理的结合其实就是Serverless的概念。开发者根本不需要关心服务器，只需要关注业务逻辑。这其实就是微服务系统与基于平台的Serverless架构相结合的过程。阿里云的FC（函数计算）和SAE（应用引擎）都致力于解决这些问题。微服务+Serverless最佳实践Serverless其实已经经历了多年的发展，它的概念可以追溯到2012年；而在2014年，AWS正式推出Lambda，掀起了Serverless的浪潮，但随之而来的是沉寂期的发展期。造成这种情况的原因是什么？总的来说，是因为函数计算的开发模式和原来的模式有很大的不同。它更适合前端应用程序而不是长时间运行的应用程序。它更倾向于基于请求的处理。因此，一些需要长时间运行的服务或应用架构，就不太能够享受到Serverless带来的灵活性和降本增效的红利。微服务架构的痛点微服务的痛点是稳定性。微服务带来了许多其他组件。比如服务发现，或者其他一些工具类产品。而这些在单体的情况下变得更加复杂，因为整个架构变成了一个网络结构。容器和容器平台其实在一定程度上帮助我们承载了微服务的运维，但是它们本身，比如容器K8S，都具有一定的复杂性。比如K8S的架构图非常复杂，也存在一些痛点：?容器镜像部署方式的差异?K8S组件运维复杂?学习成本微服务的理想状态是开发者只需要关心关于架构业务系统、其他网关CICD发布系统、审核流程、注册中心包括未付费包、告警监控、分析日志，这些都不需要开发者操心。开发者只需要关心业务系统。对开发者最有吸引力的是，他们可以只专注于业务逻辑，而无需改变原有的开发方式。专注业务逻辑，不改变原有开发方式无需关心运维底层资源。弹性可以降低空闲时间的成本优秀的工具链总结微服务系统在整个云计算发展时代都有不同的事件。比如初期部署是传统的IT设施，比如IDC机房，微服务提供静态的物理计算资源。什么是静态物理资源？例如，我们的一台服务器可能会造成资源浪费。那么第二步就是云主机时代，也就是我们都知道的VM。在阿里，是ECS，可以提供弹性的计算资源，但是它没有实质性的变化，只是说资源变得弹性了，但是对于服务和微服务的部署，包括管理运维，没有本质。太多的变化。但在云原生时代的第三阶段，云平台和云服务可以承担这些复杂的运维操作、配置和管理。例如，微服务提供的是一个运行环境和平台。这时候用户只需要关心业务系统，业务系统如何实现即可。把复杂的技术越做越简单，让用户不再感知那些复杂的操作，平台代替用户去做重复性、难维护的工作，这也符合整体计算机技术的发展方向。
