微服务组件Nacos

微服务组件Nacos

1.1.1 什么是单体架构
一个归档包（例如war格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构。（就是一个war包打天下）
1.1.2 单体架构示意图

1.1.3 单体架构的优缺点
优点:
①: 架构简单明了，没有”花里胡哨“的问题需要解决。
②:开发，测试，部署简单
缺点:
①：随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次
提交代码 ，修改每一个小bug都是心惊胆战的。
②: 部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部署的速度(15分钟)
③: 扩展成本高，根据单体架构图 假设用户模块是一个CPU密集型的模块(涉及到大量的运
算)，那么我们需要替换更加牛逼的CPU，而我们的订单模块是一个IO密集模块（涉及大量
的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无
法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU，更牛逼的内存，更牛逼的磁
盘，价格蹭蹭的往上涨。
④: 阻碍了新技术的发展。。。。。。比如我们的web架构模块 从struts2迁移到
springboot，那么就会成为灾难
1.2 微服务以及微服务架构
1.2.1 微服务的定义

①：英文:https://martinfowler.com/articles/microservices.html
②: 中文:http://blog.cuicc.com/blog/2015/07/22/microservices
微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解
耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单
独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务。
①: 比如传统的单机电商应用,有 订单/支付/库存/物流/积分财务 等模块(理解为service)
②: 我们根据 业务模型来拆分,可以拆分为 订单服务，支付服务，库存服务，物流服务，积
分服务，财务服务
③: 若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整
个服务宕机,若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使
用
1.2.3 微服务架构是什么？
微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都
在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围
绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以
用不同的编程语言编写，并使用不同的数据存储技术。
SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界
做细粒度的拆分和部署
微服务架构是一个架构风格, 提倡:
①:将一个单一应用程序开发为一组小型服务.
②:每个服务运行在自己的进程中
③:服务之间通过轻量级的通信机制(http rest api)
④:每个服务都能够独立的部署
⑤:每个服务甚至可以拥有自己的数据库
微服务以及微服务架构的是二个完全不同的概念。微服务强调的是服务的大小和对外提供的
单一功能，而微服务架构是指把 一个一个的微服务组合管理起来，对外提供一套完整的服
务。
1.2.3 微服务的优缺点
优点:
①：每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可
能改几行代码 需要了解整个系统)
②: 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就
可以了）
③: 微服务能够被2-5个人的小团队开发，提高效率
④: 按需伸缩，服务松耦合，每个服务都能够开发部署
⑤: 前后端分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注
页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参。
⑥:一个服务可用拥有自己的数据库，也可以多个服务连接同一个数据库。
缺点:
①:增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千个war
包 (k8s+docker+jenkins )
②: 服务之间相互调用，增加通信成本
③:数据一致性问题(分布式事务问题)
④:性能监控等,问题定位…
1.2.4）微服务的适用场景
合适
①:大型复杂的项目…(来自单体架构200W行代码的恐惧)
②:快速迭代的项目…(来自一天一版的恐惧)
③:并发高的项目…(考虑弹性伸缩扩容的恐惧)
不合适
①：业务稳定，就是修修bug ，改改数据
②：迭代周期长 发版频率 一二个月一次.

1.注册中心介绍
1.1 注册中心的作用
思考：不同的微服务如何维护复杂的调用关系？

//服务之间通过RestTemplate调用，url写死 String url =
“http://localhost:8020/order/findOrderByUserId/”+id; R result =
restTemplate.getForObject(url,R.class);

实现服务发现的设计思路：

服务注册中心的作用就是服务注册与发现

服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去。
服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

1.2 注册中心设计思路分析
https://www.processon.com/view/link/5e71cc85e4b011fcce9d604d

1.3 注册中心对比

2. 什么是 Nacos
   Nacos 是 Dynamic Naming and Configuration Service 的首字母简称；一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
   Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
   Nacos 的关键特性包括:
   服务发现和服务健康监测
   动态配置服务
   动态 DNS 服务
   服务及其元数据管理
   官方文档： https://nacos.io/zh-cn/docs/what-is-nacos.html
   OpenAPI文档：https://nacos.io/zh-cn/docs/open-api.html
   nacos版本： v2.1.0

Nacos 优势
易用：简单的数据模型，标准的 restfulAPI，易用的控制台，丰富的使用文档。
稳定：99.9% 高可用，脱胎于历经阿里巴巴 10 年生产验证的内部产品，支持具有数百万服务的大规模场景，具备企业级 SLA 的开源产品。
实时：数据变更毫秒级推送生效；1w 级，SLA 承诺 1w 实例上下线 1s，99.9% 推送完成；10w 级，SLA 承诺 1w 实例上下线 3s，99.9% 推送完成；100w 级别，SLA 承诺 1w 实例上下线 9s 99.9% 推送完成。
规模：十万级服务/配置，百万级连接，具备强大扩展性。

2.1 Nacos 注册中心架构和基本概念

服务 (Service)
服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service。

服务注册中心 (Service Registry)
服务注册中心，它是服务及其实例和元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。

服务元数据 (Service Metadata)
服务元数据是指包括服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。

服务提供方 (Service Provider)
是指提供可复用和可调用服务的应用方。

服务消费方 (Service Consumer)
是指会发起对某个服务调用的应用方。

2.2 Nacos注册中心核心功能
服务注册：Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。
服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。
服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。
服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存
服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)