Nginx在微服务架构中的应用1、认识微服务1.1、为什么需要微服务1.1.1、微服务是软件生产发展的必然产物1.1.2、微服务是软件开发过程的必然需求1.2、微服务的技术特点1.3、微服务的进化近几年微服务(Microservices)技术迅猛发展以SpringCloud为架构方案、Kubernetes为支撑平台成为微服务架构的主流实践方案。微服务架构中把一个大系统中的单体应用按业务功能分解成多个功能单一的服务化小系统并以API的方式使这些小系统相互协作组合成这个大系统的功能应用。以往大型的复杂单体应用被拆解后的多个微服务所代替系统中的每个微服务被独立部署彼此之间是松耦合的。每个微服务仅关注如何很好地完成自身的任务开发人员也可以更专注所负责的服务化模块使软件生产的效率得到有效提升。微服务是以多个独立的个体部署的因此微服务架构给运维工作带来了诸多挑战相对于单体应用微服务的业务 调用链更长、调用关系更复杂、故障点更多。运维人员需要考虑更多运行可用性、连续性、容量伸缩及响应速度方面的工作。Kubernetes被认为是目前最成功、影响也最大的微服务支撑方案它提供了资源调度、弹性伸缩、自动化部署等功能并完美解决了负载均衡、集群管理、有状态数据的管理等微服务面临的问题成为企业容器化微服务的首选解决方案。在微服务架构体系中Nginx也基于其自身优势不仅在Kubernetes系统中以Ingress的方式提供服务入口应用更在微服务网关等核心组件中发挥着重要的作用。1、认识微服务1.1、为什么需要微服务计算机自诞生以来极大地影响了人类的生产和社会活动软件生产以一种生产活动的方式进入了人们的生活。软件生产是知识密集型的智力活动生产过程仍以手工劳动为主。随着软件生产活动的发展不同时期生产力的需求促进着生产方式的变革表现形式从程序设计方式逐渐转变为应用架构的创新微服务便以应用架构的创新形式随着软件生产的发展逐渐演变而来成为软件生产发展的必然产物同时也是软件开发过程中的必然需求。1.1.1、微服务是软件生产发展的必然产物软件生产以程序设计为生产方式的表现形式发展经历了3个时期分别是程序设计时代、软件系统时代和软件工程时代。(1)程序设计时代20世纪50年代20世纪70年代程序设计时代的软件生产仅是程序设计主要是按照需求编写用来计算的数学程序编写者和使用者通常为同一人或同一组人是一种自给自足、个体手工劳动的生产活动。编程语言主要以早期的命令式程序设计语言为表现方式。机器语言及汇编语言是最早的命令式语言最早诞生的高级语言Fortran Ⅰ也是一种命令式语言命令式语言是基于动作的语言。以冯·诺依曼计算机体系结构为背景计算机被看作是动作的序列程序就是用语言提供的操作命令书写的一个操作序列。命令式语言支持自然公式语法如使用几条命令让计算机完成数学计算等现在的高级语言都支持这种命令式语言的设计风格。(2)软件系统时代20世纪70年代20世纪90年代软件系统时代有了数据结构的概念程序与数据构成了软件同时也产生了职业的软件开发人员并由个体手工劳作逐渐转变成作坊式合作的真正软件生产活动。由于高级语言的诞生和20世纪60年代中期计算机硬件的飞速发展计算机的应用领域及需求不断扩大软件成为一种商品。这一时期由于生产力需求的增加落后的程序设计方法严重阻碍了生产力的发展导致了第一次软件危机的爆发。为解决这一问题人们提出了结构化程序设计方法结构化程序设计约定软件开发者采用自上而下、逐步求精、模块化的方式进行程序设计整个程序的各个模块通过顺序、选择、循环的控制结构进行连接只有一个入口和一个出口。模块化的设计实现了有效的工作分工每个模块可以被不同的人编写、重用并独立测试使生产力得到巨大提升。结构化程序设计的典型代表莫过于C语言每个程序由多个源文件构成每个源文件就是一个模块不同的源文件被入口文件main.c引入后通过控制结构实现模块功能的调用。(3)软件工程时代20世纪90年代至今软件工程时代的软件生产引入了软件工程的概念软件生产被定义了生命周期程序开发也被要求遵守系统化、规范化、数量化的工程原则。随着社会的发展人们对软件的需求量剧增软件的复杂度也越来越高大规模软件常常由数百万行代码组成参与程序开发的人员数以百计结构化程序设计的问题日益凸显。此时以面向对象程序设计为代表的新的生产方式适应了生产力发展的需求成为人们的新选择。面向对象程序设计是将结构化程序设计中的数据及与数据有关的函数集成在一起形成对象而对象的类型就是类类中可以定义方法和属性等并将结构化程序设计中主程序与子程序间的从属关系变为对象间相互发送消息的平等关系。现今流行的开发语言大多是面向对象的程序设计语言采用面向对象程序设计思想开发的外部文件里可以有更加复杂的方法。通过类、方法、属性的定义使其可以处理更加复杂的场景。早期软件生产方式变革的重点都在数据结构和算法的选择上随着软件系统规模的变大及处理的场景越发复杂软件生产进入软件工程时代整个软件系统的架构设计和规范变得越来越重要数据库、网络、分布式等应用架构技术也成为软件设计的重要组成部分。软件生产方式的表现形式逐渐由内在的程序设计向外在的应用架构转变曾被使用的应用架构有垂直应用架构和面向服务架构。垂直应用架构。最早的LAMP(Linux、Apache、MySQL、PHP)是一种非常原始的垂直架构模式由于早期互联网公司的业务规模小LAMP在很长一段时间内十分流行。随着互联网应用规模的增长分层模式的垂直应用架构得到了广泛应用。分层模式的最典型模型就是MVC(Model-View-Controller)模型MVC模型充分利用面向对象的封装、继承及多态特性把代码结构分为展示层(View)、控制层(Controller)和模型层(Model)控制层负责处理用户请求通过模型层获取数据并经过展示层渲染后展示给用户。MVC模型下的应用代码通常打包在一个发布包中进行部署。在高并发场景下会使用Nginx等负载均衡对部署在多个机器上的应用进行负载分流。面向服务架构。面向服务架构(Service OrientedArchitecture, SOA)是一种松耦合、粗粒度的以服务为中心的架构以服务为基本的业务功能单元由平台接口契约来定义将业务系统服务化。按照这种方式可以将程序代码中的不同模块解耦并通过网络实现服务调用、消息交换和资源共享。它的关注点是服务注重服务的可用 性、松耦合的独立性、可任意组合编排、无状态且可被自动发现所有服务间可以通过网络、注册中心或企业服务总线(ESB)等技术方式进行通信。上述两种应用架构下的每个功能应用仍以单体应用的方式存在当软件规模复杂时代码的复杂性、维护性、创新性、可扩展性等问题依然存在。微服务架构基于面向服务架构既在程序设计方法上限制了对象类模块的无限增长使代码的复杂性得到有效控制便于开发人员维护和扩展同时又以服务化的形式增强应用架构的整合使不同的应用以服务化的形式更易相互调用以实现不同的功能。微服务架构使软件生产方式再次发生变化提升了软件生产效率成为软件生产发展中的必然产物。1.1.2、微服务是软件开发过程的必然需求用户需求不明确是软件生产供需矛盾的一个重要表现形式自软件诞生以来就一直存在于软件开发过程中。用户在见到开发出来的软件前通常自己也不清楚软件的具体需求对软件需求的描述也不够精确甚至可能存在很多错误的描述。用户在软件开发期间也会有变更需求的情况发生甚至因与开发人员所处的业务领域不同导致彼此间对需求的理解存在很大的差异。首先我们要认识到这种需求不明确存在的客观性因为它不只存在于软件生产活动中还是一种客观的社会环境特点。这一社会环境特点被称为VUCA, VUCA是易变性(Volatility)、不确定性(Uncertainty)、复杂性(Complexity)、模糊性(Ambiguity)的缩写。VUCA是如今整个社会环境的特点尤其是信息科技方面随着科技进步及互联网的快速发展社会正处于信息化爆炸的年代大数据、云计算、物联网、人工智能快速发展人们对未来充满未知和疑惑各种需求更加模糊、复杂且具有极大的不确定性。在软件开发过程中人们一直以不同的软件过程模型进行开发过程革新。最早出现的软件开发模型是瀑布模型它以一种预见式的方式向用户确认需求将开发周期从一个阶段向下个阶段逐级过渡。瀑布式的软件开发过程缺乏灵活性当遇到用户需求不明确的问题时这一缺点最为突出。敏捷开发模型顺应时代的发展成为人们的首选在它的迭代式开发模式下开发工作被组织为一系列称为迭代的实现周期短小、固定长度的小项目每次迭代都包含需求分析、开发、测试等一系列动作通过迭代开发的方式可以在每次迭代时向客户细化需求并不断调整开发过程使其更接近用户需求。敏捷开发下的迭代周期都很短通常在两周或三周左右。对于每次需求的变化软件开发都要以最快的速度去调整。为适应这种变化软件在程序设计上需要有更多可被重用的模块应用架构方面也要能够应对其不断拆分或重组带来的变化。微服务应用架构下构成服务的粒度较小代码逻辑简单、易维护、可替换性强。每个微服务都是独立运行的每个产品功能由一个或多个微服务共同实现对功能需求的变更只需增加或修改对应的微服务即可其完全满足了敏捷式开发的需求成为软件开发过程的必然选择。1.2、微服务的技术特点微服务是独立运行的、可被访问的服务单元。微服务架构是一种应用架构架构中每个微服务可以独立部署彼此之间是松耦合的。它集成了面向服务架构的诸多优点且更注重以服务为单元的低复杂度、小体积形态每个微服务代表一个较小的业务能力多个不同的微服务可以被组织成可实现更复杂功能的集合。微服务适应了客观社会环境能够有效满足敏捷开发的需求。Spring Cloud是一套完整的微服务架构实践方案它利用Java语言SpringBoot框架的开发便利性使开发人员的开发项目与其提供的各微服务组件可以很方便地进行集成使微服务架构的项目可以快速实施。本节便以Spring Cloud集成的常见的微服务架构组件为例介绍微服务架构的技术特点。微服务架构的主要技术特点如下。(1)服务注册发现微服务架构中为确保每个服务的高可用性每个微服务都由多个部署相同代码的节点构成每个微服务都会把自己的所有节点注册到注册中心。对于服务调用方可以通过注册中心查询并发现期望调用服务的节点调用地址以实现服务访问通信。注册中心会提供相应的检测机制以确保被发现的节点地址是可用的。常用的服务注册与发现组件有Spring Cloud Euraka、ZooKeeper、etcd、 Consul。(2)服务网关微服务架构中每个微服务都提供了一个小的应用功能对于客户端来讲要想完成一个较复杂的功能需要调用不同的微服务。为了便于客户端的访问及访问管理在客户端和服务端之间增加了服务网关组件。服务网关为所有的微服务提供了一个唯一的入口通过不同的路径将客户端的请求路由到不同的内部服务。通过服务网关还可以提供统一的用户鉴权、跨域访问、流量管控及数据整形等功能既方便了微服务之间的访问又减轻了开发工程师的工作量。常见的服务网关组件有Spring Cloud Zuul、Kong基于OpenResty及Gravitee。(3)配置中心在传统模式下每个应用都会存在对运行时的数据库、Redis等组件或不同硬件配置下的运行参数进行修改的需求这些修改都以配置文件的形式保存在代码包中。当每个微服务被拆分为更小的体积并独立部署时部署节点的数量急剧增加每个节点配置的修改也变得非常复杂。为了方便配置的修改配置中心提供了一种配置文件与应用代码分离、集中修改的方法实现配置修改操作。每个服务将配置存储在配置中心在每次启动时按需读取配置内容完成配置加载的需求。常见的组件有Spring CloudConfig、Apollo及Disconf。(4)服务容错保护微服务架构将原有的单体应用拆分为多个可独立运行的服务使很多以前在单应用内存级的调用变成了网络调用。由于网络调用的不确定性或被调用方的可用性等因素极大 地增加了访问响应延迟等问题的发生相应地调用方自身在等待期间无法响应上级服务的当前调用若此时仍不断有相同的请求被发送过来便会造成请求积压甚至导致服务瘫痪。基于这种考量Spring Cloud在微服务架构中提供了断路器、线程隔离等一系列服务容错保护机制以对调用的请求进行监控当下游请求出错达到阈值时将自动启动熔断不再调用下游服务直接返回错误信息当检测到下游服务器恢复时则继续向下游服务器发送请求。常见的服务容错保护组件有Spring Cloud Hystrix、Linkerd、Istio。(5)分布式链路跟踪在单体应用拆分为多个可独立运行服务的微服务架构中服务节点不断增加服务间的调用关系变得越发复杂。通常一个客户端请求会引发多个及多层级服务的调用期间除了需要对容错保护机制进行监控还需要对因调用关系而引发的链路性能进行分析监控。分布式链路跟踪会对客户端访问的每个请求创建一个唯一的跟踪标识当请求在访问链路中流转时跟踪系统将根据该跟踪标识实现对每个请求链路的监控。这些监控信息可以包括访问路径中的服务名称、请求耗时、方法错误等。常见的分布式链路跟踪组件有Spring Cloud Sleuth、Jaeger和Zipkin。(6)微服务进程间的通信微服务是通过网络实现通信的服务的相互调用是进程间的通信调用。对于进程间的通信在通信机制上有两种一种是IPC(Inter-Process Communication)机制其以REST风格为代表并完全通过HTTP协议实现相对更加通用、规范另一种是RPC(Remote Procedure Call)机制典型应用是Google开源的gRPC框架它基于HTTP/2协议使不同服务间的进程可以像调用本地方法一样调用远程方法。很多语言都支持这两种机制的实现不同语言编写的服务都可以实现跨语言的进程间通信。在通信模式上有同步和异步之分在同步模式下服务间调用需要被调用方即时响应在高并发场景下会出现阻塞在异步模式下服务间通过消息组件实现间接通信可有效避免阻塞同时还支持一对多的通信实现常用的消息组件有RabbitMQ、Kafka。(7)支撑平台碎片化是微服务的主要特征因而微服务及微服务架构的运维变得更加复杂。容器化技术以进程级别虚拟化使每个微服务运行在传统物理机上基于容器的管理系统Kubernetes为微服务提供了自动化的管理解决方案。Kubernetes提供了包括自动化部署、运维、监控、负载均衡、灰度访问等功能有效解决了碎片化微服务的运维管理问题。1.3、微服务的进化微服务架构技术仍在不断创新人们围绕微服务不断提出不同的部署和使用方式使得微服务架构技术不断进化。(1)服务网格服务网格(Service Mesh)是一种微服务架构形式它将微服务独立运行时所依赖的服务组件功能与业务进程分离使其作为一种可配置的基础设施层存在每个微服务都包含一个基础设施并在微服务间为业务进程提供快速、可靠、安全的通信保障。被分离的基础设施叫作Sidecar它实现了服务发现、负载均衡、链路跟踪、访问日志、身份验证、授权及容错保护等功能使业务进程只关注于具体业务的实现即可。服务网格起源于开源项目Linkerd并因Google联合IBM、Lyft发起的Istio项目得到广泛推广。Istio是基于Kubernetes容器管理框架实现的并与Kubernetes系统实现了紧密的结合它使用了Kubernetes的服务名及服务发现机制。Istio的Sidecar可实现自动注入Pod并使集群内服务间的通信完全可被Istio监控。Istio分为控制面板(Control Plane)和数据面板(DataPlane)。控制面板负责实现与用户间的交互实现监控数据的展示和数据面板相关配置的修改及存储。数据面板由每个微服务的基础设施(Sidecar)组成其负责与控制面板间的通信及具体微服务进程间的通信基础功能的实现Istio的Sidecar是通过Envoy实现的。服务网格将Spring Cloud微服务架构中诸多组件通过基础设施层利用Kubernetes系统的特点注入微服务每个节点的Pod中该方式对业务代码无侵入性使开发工程师可以更专注于业务功能的实现极大地减轻了进行软件开发的工作量提高了软件生产效率。(2)无服务器化无服务器化(Serverless)并不代表没有服务器服务器作为底层资源仍是软件运行的基础它并不是不需要服务器而是共享服务器资源。每个用户只需要考虑自己业务应用所需要的计算资源而不需要关心其运行在什么样的服务器上。无服务器化是公有云产品的一个延伸它极大地改变了程序设计的方法对于非无服务器化下的程序开发开发工程师需要对实现的业务代码加载诸多基础函数、进行打包编译和部署发布等一系列的操作。无服务器化则使开发工程师只需考虑具体代码的实现甚至可以仅提供一段函数代码就可以由无服务器化云平台完成一系列部署、发布、运行等操作。开源无服务器化应用Kubeless是基于Kubernetes系统实现的它支持Python、Node.js、Ruby、PHP、Go、.NET等语言的运行时(runtime)也支持自定义运行时的方法。当用户提交一段函数代码或文件后它会将这段函数与其依赖的运行时封装成可运行的服务并以Pod的形式运行在Kubernetes集群中调用方只需要通过Kubernetes提供的Service及Ingress提供的端口使用基于HTTP的REST方式即可实现相应函数方法的调用。无服务器化架构方式更细粒度地拆解了微服务它使每个函数都可成为一个微服务的最小功能单元极大减少了开发工程师所需考虑的非业务类额外因素更包括代码可复用的公共组件等使开发工程师们更专注于业务功能的实现可以更快速地完成开发任务。(3)持续进化微服务概念自出现以来大家一直在思考什么是“微”​就是微服务到底有多小、如何对现有的单体应用进行拆分。这个问题似乎很复杂也让初识微服务的人对其望而却步但无论是Spring Cloud架构、服务网格还是无服务器化都是将软件生产过程中可被重用的部分与业务代码分离其本质上仍是结构化程序设计思想的延续就是将复杂任务按照功能进行拆分逐步细化并通过模块化的方式提高代码的可重用性可将这类微服务架构统一称为结构化微服务架构。在我们的认知中我们周围所有客观存在的都是物质每个物质都有它的物理属性和化学属性分子、原子、离子是构成物质最基本的微粒。在自然界物质的种类形态万千物质的性质多种多样但它们都有其特性那就是客观存在并能够被观测。我们可以将微服务架构中的微服务看作一个物质对象微服务的名称、分类、接口地址、参数说明被定义为它的物理属性微服务的接口被传递不同参数时产生的不同返回结果被定义为它的化学属性。对象类是组成微服务物质的分子具有网络服务接口能力的一个或多个对象类构成一个微服务。这是以面向对象的思想构建微服务架构多个对象类达到一定的规模就变成了单体应用多个微服务之间被按照微服务架构的规则自动注册、彼此发现、共享数据、进行统一路由管理等则构成了更复杂的服务。微服务在我们的现实世界里还需要不断进化它已经变成客观存在但以面向对象微服务架构的思想来看它还不具备可被观测的特性每个微服务的物理及化学属性应该形成一种标准和规范可以在一定的授权范围内被用户观测和使用。例如REST风格或gRPC都是微服务化学反应的一种进程通信机制无论使用哪一种都应是物理属性中被声明的一部分可以被外部用户直接观测。人工智能技术已渗透到我们每个人的生活之中未来计算机科学的各种应用都将以人工智能技术的方式体现。可被观测是微服务的一种基本特性能够主动交流才是智能的体现在具有智能特征的微服务架构体系中每个微服务都应该可以智能地告诉服务中心我是谁、我能做什么、如何和我交流并产生化学反应以及我的进化史。以公司为实体范围的内部用户将共享每个微服务提供的功能用户通过服务中心检索每个分类的微服务并按照自己的需求组装更复杂的功能。当网络中不存在符合功能的微服务时工程师们可以根据需求添加新的微服务或对相似的微服务进行升级。服务中心管理着每个微服务的版本并根据智能算法和微服务提供的测试声明确保其化学属性的可用性。每个微服务均以对象类为最小粒度进行构建当功能扩展的版本升级后被智能中心扫描发现所包含的对象类达到技术体系约定的数量时便会被要求拆分为多个独立的微服务。由于微服务的体量足够小、更加便于阅读所以每个工程师将不再受传统部门或项目组的约束其可自由地添加或更改自己所需要的微服务版本包括更换为自己熟悉的编程语言。每个微服务接口名称将像物质分类一样被社会标准统一制定即便开发人员遇到跨领域的开发需求也只需在服务中心检索通用类目获得相应解释和定义并按照约定的名称定义接口。总之自然界中的物质形态万千同样微服务应用的功能也是无穷无尽的所以按照应用的功能进行拆分是无法找到固定拆分方法的只要以对象类为最小维度构建并确保其有物理和化学属性的特征就可以构建一个微服务。笔者认为面向对象的微服务架构将是微服务进化的方向微服务的粒度也只应与包含对象类的数量有关。