第十章第二节 微服务架构

微服务架构2024年11月19日202410.2.1微服务架构概念10.2.2微服务核心组件10.2.3典型的微服务架构

第十章第二节微服务架构contents目录10.2.1微服务架构概念01微服务架构概念微服务架构是SOA（面向服务架构）的一种变体。其实这个词是从2014年MartinFowler发表的一篇文章《AreMicroservicestheFuture》开始被业界广传而火起来的。微服务架构强调去中心化管理，尽可能的保持服务的自治性和独立性。强调能力通过不同的小的服务进行整合获取。这样可以对服务进行有选择的纵向和横向扩展，同时也避免了单个系统的臃肿和功能的堆叠、耦合。微服务架构的概念如图10-4所示。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源，微服务是需要与业务能力相匹配，意味着如果能力模型粒度的设计是错误的，就必须付出很多代价。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，需要在配置和资金模型的基础上考虑到基础设施的成本问题。[1][2][3]图10-4微服务架构的概念[1]洪华军，吴建波，冷文号.一种基于微服务架构的业务系统设计与实现[J],计算机与数字工程,2018(046)001.[2]郭栋，王伟，曾国荪.一种基于微服务架构的新型云件PaaS平台[J],信息网络安全,1671-1122,2015,(11),15-20.[3]李忠民.—兼谈微服务架构的实施实践[J]．科技创新与应用，2016,(35),95-86.02微服务的基本思想微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台，使部署、管理和服务功能交付变得更加简单。微服务是利用组织的服务投资组合，然后基于业务领域功能分解它们，在看到服务投资组合之前，它还是一个业务领域。10.2.2微服务架构核心组件01微服务架构核心组件微服务架构的设计目标是提高系统的可伸缩性、灵活性和可维护性。在实施微服务架构时，常用的组件包括[4][5]：1.服务注册与发现组件：服务注册与发现组件用于管理和跟踪微服务的注册和发现。它允许服务在启动时向注册中心注册自己的地址和元数据，并在需要调用其他服务时从注册中心获取相应的服务地址。常见的服务注册与发现组件包括Consul、Eureka和ZooKeeper。2.API网关：API网关是微服务架构中的入口点，用于处理外部请求并将其路由到相应的微服务。它可以提供身份验证、授权、负载均衡和缓存等功能，同时还可以对请求进行转换和过滤。常见的API网关包括Nginx、Kong和Zuul。3.配置管理组件：配置管理组件用于集中管理微服务的配置信息。它可以提供动态配置更新、版本控制和故障恢复等功能。常见的配置管理组件包括SpringCloudConfig和Consul。4.消息队列：消息队列用于实现微服务之间的异步通信。它可以将消息从一个服务发送到另一个服务，实现解耦和削峰填谷等功能。常见的消息队列包括RabbitMQ、Kafka和ActiveMQ。5.负载均衡器：负载均衡器用于将请求分发到多个相同的微服务实例，以提高系统的可伸缩性和可用性。它可以根据负载情况动态调整请求的分发策略。常见的负载均衡器包括Nginx、HAProxy和Ribbon。6.分布式追踪系统：分布式追踪系统用于跟踪和监控微服务之间的调用链路。它可以记录请求的传递路径和各个服务的处理时间，帮助开发人员分析和排查系统性能问题。常见的分布式追踪系统包括Zipkin和Jaeger。7.容器化平台：容器化平台用于部署和管理微服务的容器。它可以提供自动化的容器编排、弹性伸缩和服务发现等功能，简化了微服务的部署和管理工作。常见的容器化平台包括Docker和Kubernetes。以上是微服务架构中常用的组件，每个组件都有其特定的功能和用途，可以根据具体的需求选择合适的组件进行使用。在实施微服务架构时，需要综合考虑系统的可伸缩性、可用性和可维护性等方面的需求，合理选择和配置组件，以实现高效、稳定和可扩展的微服务架构。10.2.3微服务架构案例分析01电商系统的微服务架构图10-5电商系统的微服务架构以一个电商系统为例，进行基于微服务架构的设计，设计目的是有效的拆分应用，实现敏捷开发和部署。微服务通常由重写一个模块开始。要把整个巨石型的应用重写是有很大的风险的，也不一定必要。向微服务迁移的时候通常从耦合度最低的模块或对扩展性要求最高的模块开始，把它们一个一个剥离出来用敏捷地重写，可以尝试最新的技术和语言和框架，然后单独布署。它通常不依赖其他服务。微服务中常用的APIGateway的模式主要目的也不是重用代码，而是减少客户端和服务间的往来。APIgateway模式不等同与Facade模式，可以使用如future之类的调用，甚至返回不完整数据。要实际的应用微服务，需要解决以下四点问题：1.客户端如何访问这些服务。2。每个服务之间如何通信。3.如此多的服务，如何实现？4.服务挂了，如何解决？（备份方案，应急处理机制）02客户端如何访问这些服务图10-6电商系统的微服务架构的访问客户端如何访问这些服务，原来的Monolithic方式开发，所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的一般都在独立的虚拟机上的Java进程了。客户端UI如何访问？后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。所以，一般在后台N个服务和UI之间一般会一个代理或者叫APIGateway，作用包括：①提供统一服务入口，让微服务对前台透明。②聚合后台的服务，节省流量，提升性能。③提供安全，过滤，流控等API管理功能。其实这个APIGateway可以有很多广义的实现办法，可以是一个软硬一体的盒子，也可以是一个简单的MVC框架，甚至是一个Node.js的服务端。他们最重要的作用是为前台（通常是移动应用）提供后台服务的聚合，提供一个统一的服务出口，解除他们之间的耦合，不过APIGateway也有可能成为单点故障点或者性能的瓶颈。03每个服务之间如何通信图10-7电商系统微服务架构的服务间通信所有的微服务都是独立的Java进程跑在独自的虚拟机上，所以服务间的通信就是IPC（interprocesscommunication），已经有很多成熟的方案。现在基本最通用的有两种方式：同步调用：①REST（JAX-RS，SpringBoot），②RPC（Thrift,Dubbo）异步消息调用：(Kafka,Notify,MetaQ)同步和异步的区别：一般同步调用比较简单，一致性强，但是容易出调用问题，性能体验上也会差些，特别是调用层次多的时候。RESTful和RPC的比较也是一个很有意思的话题。一般REST基于HTTP，更容易实现，更容易被接受，服务端实现技术也更灵活些，各个语言都能支持，同时能跨客户端，对客户端没有特殊的要求，只要封装了HTTP的SDK就能调用，所以相对使用的广一些。RPC也有自己的优点，传输协议更高效，安全更可控，特别在一个公司内部，如果有统一个的开发规范和统一的服务框架时，开发效率优势更明显些。就看各自的技术积累实际条件，自己的选择了。03每个服务之间如何通信图10-7电商系统微服务架构的服务间通信所有的微服务都是独立的Java进程跑在独自的虚拟机上，所以服务间的通信就是IPC（interprocesscommunication），已经有很多成熟的方案。现在基本最通用的有两种方式：同步调用：①REST（JAX-RS，SpringBoot），②RPC（Thrift,Dubbo）异步消息调用：(Kafka,Notify,MetaQ)而异步消息的方式在分布式系统中有特别广泛的应用，他既能减低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性；还有就是后台服务一般要实现幂等性，因为消息发送出于性能的考虑一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）；最后就是必须引入一个独立的broker，如果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。04如此多的服务，如何实现？图10-8电商系统微服务架构的服务实现在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。服务之间如何相互感知？服务如何管理？这就是服务发现的问题了。一般有两类做法，也各有优缺点。基本都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法，找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。客户端做的优点：架构简单，扩展灵活，只对服务注册器依赖。缺点是客户端要维护所有调用服务的地址，有技术难度，一般大公司都有成熟的内部框架支持，比如Dubbo。服务端做的优点：简单，所有服务对于前台调用方透明，一般在小公司在云服务上部署的应用采用的比较多。05服务挂了，如何解决？图10-5电商系统的微服务架构前面提到，Monolithic方式开发一个很大