Web相关工具和框架

1、微服务①、定义微服务将一个复杂的服务拆分为多个不同功能的小型独立服务每个微服务专注于单一业务如用户服务验证用户信息、订单服务处理订单、支付服务处理支付降低了业务复杂度和耦合度。各个微服务可以使用不同的技术栈实现如Java、Go、Python微服务之间通过RPC或REST或MQ进行通信每个微服务可以独立部署和扩展。集群相同功能的服务多节点部署。分布式不同功能的服务部署在不同节点上。微服务不同功能的服务可以部署在多个节点常见即分布式也可以部署在单机上。②、API网关微服务架构中一般是有一个或几个服务面向客户而且客户不是直接访问微服务而是通过API网关来将客户请求路由到后端相应的服务后端服务的响应也是由API网关转发给客户。API网关一般还提供负载均衡、缓存等功能。Spring Cloud Gateway这种API网关还提供鉴权认证用户身份验证、权限控制、黑白名单、限流速率限制、请求配额等防止服务过载、监控和日志集中收集API请求指标、错误处理提供统一的错误响应格式、跨域处理等横切面功能。Spring Cloud Gateway 通过 Route Predicate Filter 三大核心组件构建网关逻辑Route路由定义请求转发规则Predicate断言匹配 HTTP 请求条件如 Path、Header、Method以决定是否应用路由Filter过滤器在请求转发之前或之后执行指定逻辑。③、微服务集群架构API网关后面的服务可以是集群方式的如订单服务部署为3台节点的集群支付服务部署为3台节点的集群API网关从注册中心如Eureka、Nacos、ConsulSpring Cloud Gateway能与这些注册中心无缝集成获取后端服务实例列表API网关通过指定的负载均衡策略来选择集群中的一个节点进行请求转发后端服务的高可用由注册中心来提供。也可以开启API网关主动或被动监测后端服务健康状态来增强后端服务的高可用。主动检查API网关定期向后端服务的/health端点发送探测请求如连续3次失败标记为不健康连续2次成功恢复为健康将故障节点从可用服务列表移除。被动防御API网关在请求失败时自动重试其他服务实例。API网关也建议进行集群部署防止一个网关挂了后整个网络入口关闭。API网关集群的负载均衡和高可用可以由nginx或云厂商SLB来实现。④、API网关和Nginx/SLBNginx/SLB针对的是访问的总入口属于流量网关API网关是业务相关的服务属于业务网关业务网关一般部署在流量网关之后、业务系统之前。API网关是将请求转发给后端不同业务功能的微服务Nginx/SLB是将请求转发给后端相同功能服务的集群。微服务架构属于业务架构设计层面集群架构属于部署架构层面。2、Dubbo和NacosDubbo是阿里的RPC框架其使用Nacos来实现服务的发现和治理即注册中心功能Dubbo原来使用Zookeeper作为注册中心现在改成了Nacos。如下所示服务先向注册中心进行注册发送服务的IP、端口、接口方法服务的消费者向注册中心订阅服务注册中心会返回给消费者服务的相关信息地址、端口等如果有台服务的话注册中心返回的就是服务列表。消费者从服务列表中可以基于负载均衡算法选一台服务来进行服务的调用。当有新的服务或远程调用方法注册到注册中心时, 注册中心会通知消费者当有服务下线注册中心也会通知消费者。注册中心始终不代替调用者发送请求到服务提供者它只是告诉服务消费者服务方地址调用方根据具体地址请求服务服务提供方可以平滑增加或减少机器。服务消费者和服务提供者还可以定时将服务调用次数、调用时间等信息发送给监控中心Monitor用于监控如下所示服务的提供者需要集成Nacos客户端Jar包形式Spring中可以通过引入相关依赖来集成来实现服务注册和健康检测Nacos 1.x通过HTTP POST请求进行服务注册Nacos客户端每5秒向Nacos Server发送一次心跳包若15秒内未收到心跳将实例标记为不健康30秒内未收到心跳将实例从服务列表中剔除Nacos 2.x使用gRPC来与Nacos Server建立长连接在长连接中通过Protocol BuffersProtobuf进行序列化传输以实现服务的注册将IP、端口、元数据等服务实例信息发送给Nacos服务端和健康检测通过长连接的keepAlive机制维持连接Nacos客户端默认定期5秒发送心跳包。Nacos对服务的健康检测除了“客户端心跳上报”模式还支持“服务端主动探测”模式注册中心即Nacos Server每5秒向服务实例发起健康检查其支持TCP、HTTP、MySQL等多种探测方式。客户端心跳上报模式适合微服务这种临时实例服务实例可随时启停服务端主动探测模式适用于持久化实例服务如数据库服务。服务的消费者同样需要集成Nacos客户端来实现订阅功能Nacos 1.x通过HTTP GET请求定期轮询服务列表默认30秒一次Nacos 2.x通过服务端推送机制来实现服务变更的毫秒级通知。3、EurekaEureka类似Nacos也是用来实现服务注册与发现它是Spring Cloud默认的也是推荐的服务注册中心适合与Spring Cloud Gateway、Spring微服务进行搭配使用。Eureka与Nacos区别①、Eureka客户端与服务端注册中心之间通过REST进行通信与Nacos 1.X类似。新版本的NacosNacos 2.x则使用grpc长连接服务正常上线、下线的话Nacos能做到毫秒级感知。②、Eureka 仅支持“客户端心跳上报”模式客户端假死客户端还能正常发送心跳但不能提供正常的业务服务如业务线程死锁或阻塞、线程池锁死等情况的话Eureka服务端无法感知防止客户端假死情况无法检测的方法是通过配置Eureka来开启Actuator健康检查这样Eureka客户端不再是简单的发送心跳而是会调用/actuator/health端点来获取服务真实状态——Spring Boot Actuator默认提供actuator/health路径的处理方法该方法会检查进程是否存活、数据库连接/Redis连接/RabbitMQ是否正常如果配置了数据库、redis、RabbitMQ当检测出异常的话就直接上报给Eureka服务端来通知服务故障。解决客户端假死情况无法检测问题的推荐方式是使用Nacos然后选择“服务端主动探测”模式由服务端向服务指定的业务路径发送请求。Nacos设置使用“服务端主动探测”模式的话是在服务提供者的配置中明确指定实例为非临时持久化如下所示服务端探测模式默认使用TCP进行探测——Nacos 服务端向服务提供者建立TCP连接端口号使用服务使用的端口号如80是否成功来判断服务是否健康。为了检测业务状态需要在注册时通过元数据metadata指定一个HTTP检查端点路径如下所示。然后需要编写HTTP检查端点路径对应方法以使路径能够正常访问返回状态码2xx/3xx 表示健康。也可以集成 Spring Boot ActuatorActuator会自动聚合数据库/redis连接、磁盘空间等关键组件的状态当数据库断开时该端点状态会变为DOWNNacos Server探测到后便会将实例标记为不健康。Actuator的检测路径应该配置成与Nacos元数据metadata指定的HTTP检查端点一致。③、Nacos健康检测的心跳包默认间隔发送时间比的Eureka要短Nacos心跳间隔为5秒客户端心跳上报模式下服务下线判断时间为30秒Nacos心跳间隔为30秒服务下线判断时间为90秒Eureka Server通过定时任务默认60秒检查实例状态执行剔除或标记操作。4、CAP BASE1、CAPCAP定理指的是在一个分布式系统中Consistency一致性、 Availability可用性、Partition tolerance分区容错性这三个基本需求最多只能同时满足其中的2个。一致性 数据在多个节点之间能够保持一致。可用性服务一直处于可用的状态每次请求都能获得正确的响应。分区容错性分布式系统在遇到任何分区故障的时候仍然能够对外提供服务。对于分布式系统来说是避免不了分区的所以分区容错性是一定要满足的那么在满足分区容错的基础上能不能同时满足一致性和可用性比如现在有两个分区N1和N2N1和N2分别有不同的服务S1和S2以及不同的分区存储D1和D2。用户访问了N1修改了D1的数据后立即又有用户再次访问请求落在了N2此时D1和D2的数据不一致。要保证数据一致性的话第二次访问的时候要等待N1分区修改的数据同步到N2上而同步的时间是无法保证的即同步时间无限延长无法保证可用性。要保证可用性的话第二次访问的时候就立即返回数据但是此时响应的数据和D1不一致一致性无法保证。由上面可得出CAP三者不可同得对于分布式系统分区是客观存在的必须保证P所以只能是选择CP without A或者AP wihtout C。CP即每个写请求都需要在分区之间强一致来保证数据一致性但这会导致同步时间无限延长很多传统的数据库分布式事务都属于这种模式。AP即为了高可用每个节点只使用本地数据提供服务而这样会导致全局数据的不一致性现在众多的NoSQL都属于此类。对于微服务中作为注册中心的组件的话ZooKeeper是 CP架构比如在 Leader 选举过程中或者半数以上的机器不可用的时候服务就是不可用的。Eureka则是 AP架构Eureka 保证即使大部分节点挂掉也不会影响正常提供服务只要有一个节点是可用的就行了。只不过这个节点上的数据可能并不是最新的。Nacos 不仅支持 CP 也支持 AP。2、BASEBASE 是指BABasically Available基本可用、SSoft-state软状态、EEventually Consistent最终一致性。BA基本可用出现故障的时候允许损失部分可用性即保证核心可用。比如电商大促时为了应对访问量激增以保证购物系统的稳定性部分用户可能会被引导到降级页面这属于功能损失。再比如正常情况下的搜索引擎0.5秒即返回给用户结果而基本可用的搜索引擎可以在2秒返回结果这属于响应时间上的损失。软状态指允许系统在不同节点的数据副本之间进行数据同步的过程存在延时软状态不能违背“基本可用”的要求。软状态相当于是“弱一致性”即不一定能读到最新的值也不能保证在一定时间后读取到的数据是最新的只会尽量在某个时刻达到数据一致的状态。最终一致性系统中所有节点的数据副本在经过一段时间的同步后最终能够达到一个一致的状态。相当于是弱一致性的升级版系统会保证在一定时间内达到数据一致的状态。一般常用的是最终一致性但是也有一些对一致性要求比较高的比如银行的交易系统这种要保证强一致性。5、Web serviceWeb service是提供给外部使用的通过Web调用的一组API它是一种跨语言和跨平台的远程调用技术。比如提供天气查询的Web service使用java或php等都能够对其进行调用。Web service其实是一种架构规范所以可以在任何支持这些标准规范的环境Windows,Linux中使用。WebService的理念是专业的事情交给专业的人去做比如我们的服务中需要获取天气信息、保存照片等功能那么可以使用提供天气预报的WebService来获取天气使用提供相册功能的WebService来保存照片而不用自己来一一实现这些功能。webService有三要素SOAP、WSDL、UDDI如下所示客户端通过 UDDI 注册表注册中心查找服务UDDI 指向 WSDL 描述服务端的服务信息户端和服务端通过 SOAP 消息基于HTTP的XML数据格式交换信息。可以看到WebService符合 Web 服务体系架构客户端-注册中心-服务端。目前Web service除了使用SOAP以外还增加了更简洁的Restful架构在数据格式上也增加了json等轻量级格式的使用。考虑性能时不建议使用WebService。6、Docker对于一些软件比如IE如果我们想安装新老版本到同一台电脑上进行测试的话是不行的只能安装虚拟机一个版本的IE对应一个虚拟机。还有就是有可能两个软件之间有冲突比如360和腾讯管家它们不能同时安装到一台电脑上只能使用虚拟机来隔离两个软件。再比如我们在测试环境Ubuntu上安装的软件其在正式环境centos上不支持该软件只能使用虚拟机了。上面这些问题除了使用虚拟机解决外还可以使用Docker。Docker可以实现类似虚拟机隔离应用环境的功能并且开销比虚拟机小它就是一种轻量级、进程级的VM。Docker并不会运行一个独立的操作系统而是提供一个“运行环境”来运行应用这个“运行环境”里包含操作系统库、运行库、第三方库等来为应用服务。多个“运行环境”就提供了多个互隔离的用户空间让应用进程之间不会相互影响这些相互隔离的用户空间就像一个大盒子里面装着各种零件应用一样这种技术就叫容器技术。容器Container给应用进程提供了一个“运行环境”使进程运行得就好像在一个独立的操作系统上。相比虚拟机Docker这样的容器技术属于轻量级的虚拟化启动时间很快几秒钟就能完成而且它对资源的利用率很高一台主机可以同时运行几千个Docker容器。此外Docker占的空间很小虚拟机一般要几GB到几十GB的空间而Docker容器只需要MB级甚至KB级。容器化技术具有可移植性其不依赖具体的操作系统或云平台比如在阿里云或腾讯云直接随意迁移。在开发的时候经常需要安装MySQL、Redis、Kafka以及Kafka依赖的ZooKeeper等服务使用Docker Desktop来安装运行这些服务的话会很方便比如我们使用一条Docker命令就能下载和安装MySQL。在运行Docker容器前需要编写Docker File通过 Docker File 生成指定的镜像然后才能运行 Docker 容器。我们在自己的电脑、测试环境电脑以及正式环境电脑上使用相同的Docker File就能生成相同的镜像相同的操作系统、第三方软件支持等这样就能避免操作系统不同、运行环境不同等带来的问题。一般情况下都不需要从头开始编写 Docker File在 Docker Hub 中有来自世界各地的工程师编写好的镜像你可以基于此修改。如下所示我们使用Docker来打包和发布应用会很方便如下所示我们在build目录下编写一个docker-compose.yml文件来定义我们要运行的所有服务在该文件中我们定义了MySQL、Redis、Kafka以及Kafka依赖的ZooKeeper服务各服务均暴露标准端口且MySQL的root口令设置为password第一次启动MySQL时使用sql / schema.sql文件初始化数据库表结构。所有数据盘均挂载到build目录下的docker目录。version: 3 services: zookeeper: image: bitnami/zookeeper:3.5 container_name: zookeeper ports: - 2181:2181 environment: - ALLOW_ANONYMOUS_LOGINyes volumes: - ./docker/zookeeper-data:/bitnami kafka: image: bitnami/kafka:3.0 container_name: kafka ports: - 9092:9092 depends_on: - zookeeper environment: - KAFKA_BROKER_ID1 - KAFKA_CFG_LISTENERSPLAINTEXT://:9092 - KAFKA_CFG_ADVERTISED_LISTENERSPLAINTEXT://127.0.0.1:9092 - KAFKA_CFG_ZOOKEEPER_CONNECTzookeeper:2181 - KAFKA_CFG_AUTO_CREATE_TOPICS_ENABLEtrue - ALLOW_PLAINTEXT_LISTENERyes volumes: - ./docker/kafka-data:/bitnami redis: image: redis:6.2 container_name: redis ports: - 6379:6379 volumes: - ./docker/redis-data:/data mysql: image: mysql:8 container_name: mysql ports: - 3306:3306 command: --default-authentication-pluginmysql_native_password environment: - MYSQL_ROOT_PASSWORDpassword volumes: - ./sql/schema.sql:/docker-entrypoint-initdb.d/1-schema.sql:ro - ./docker/mysql-data:/var/lib/mysql以后随着业务规模逐渐扩大容器越来越多可以使用kubernets俗称k8s来协调和调度这些容器保障升级应用程序时不会中断服务以及监视应用的运行情况、故障处理、批量重启应用、负载均衡等。Docker 是一个容器化平台而 k8s 是 Docker 等容器平台的协调器k8s又称为容器的编排管理工具它可以使我们应用的部署和运维更加方便其它类似的还有Docker Swarm。7、Kubernets当我们使用的Docker容器越来越多的时候可能就需要使用K8SKubernets来管理这些容器。K8S可以实现以下功能容器挂掉后使用K8S来自动重启容器协调容器之间的通信编排容器使它们按照一定的顺序和逻辑运行监控容器的CPU等使用情况监视容器内应用的运行情况不中断应用服务来升级应用程序。