Alibaba微服务组件Nacos注册中心实战
微服务架构
单机架构
一个归档包（例如war格式）包含了应用所有功能的应用程序，我们通常称之为单体应用。架构单体应用的方法论，我们称之为单体应用架构。（就是一个war包打天下）
单体架构示意图
单体架构的优缺点
优点
- 架构简单明了，没有”花里胡哨“的问题需要解决。
- 开发，测试，部署简单
缺点
- 随着业务扩展，代码越来越复杂，代码质量参差不齐(开发人员的水平不一),会让你每次提交代码 ，修改每一个小bug都是心惊胆战的。
- 部署慢(由于单体架构，功能复杂) 能想像下一个来自200W+代码部署的速度(15分钟)
- 扩展成本高，根据单体架构图 ；假设用户模块是一个CPU密集型的模块(涉及到大量的运算)，那么我们需要替换更加牛逼的CPU，而我 们的订单模块是一个IO密集模块（涉及大量的读写磁盘）,那我们需要替换更加牛逼的内存以及高效的磁盘。但是我们的单体架构上 无法针对单个功能模块进行扩展，那么就需要替换更牛逼的CPU，更牛逼的内存，更牛逼的磁盘，价格蹭蹭的往上涨。
- 阻碍了新技术的发展。。。。。。比如我们的web架构模块 从struts2迁移到springboot，那么就会成为灾难性
微服务架构
微服务的定义
英文:https://martinfowler.com/articles/microservices.html
中文:http://blog.cuicc.com/blog/2015/07/22/microservices
微服务核心就是把传统的单机应用，根据业务将单机应用拆分为一个一个的服务，彻底的解耦，每一个服务都是提供特定的功能，一个服务只做一件事,类似进程，每个服务都能够单独部署，甚至可以拥有自己的数据库。这样的一个一个的小服务就是微服务。
- 比如传统的单机电商应用,有 订单/支付/库存/物流/积分等模块(理解为service)
- 根据业务模型来拆分,可以拆分为 订单服务，支付服务，库存服务，物流服务，积分服务
- 若不拆分的时候，我的非核心业务积分模块 出现了重大bug 导致系统内存溢出，导致整个服务宕机,若拆分之后，只是说我的积分微服务不可用，我的整个系统核心功能还是能使用
微服务的特点
独立部署，灵活扩展
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如用户服务，商品服务）为单位进行部署。
资源的有效隔离
微服务设计的原则之一，就是每一个微服务拥有独立的数据源，假如微服务A想要读写微服务B的数据库，只能调用微服务B对外暴露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。
团队组织架构的调整
微服务设计的思想也改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端有前端的团队，后端有后端的团队，DBA有DBA的团队，测试有测试的团队。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。
微服务的优缺点
优点
- 每个服务足够小,足够内聚，代码更加容易理解,专注一个业务功能点(对比传统应用，可能改几行代码 需要了解整个系统)
- 开发简单，一个服务只干一个事情。（加入你做支付服务，你只要了解支付相关代码就可以了）
- 微服务能够被2-5个人的小团队开发，提高效率
- 按需伸缩，服务松耦合，每个服务都能够开发部署
- 前后端分离, 作为java开发人员，我们只要关系后端接口的安全性以及性能，不要去关注页面的人机交互(H5工程师)根据前后端接口协议，根据入参，返回json的回参。
- 一个服务可用拥有自己的数据库，也可以多个服务连接同一个数据库。
缺点
- 增加了运维人员的工作量，以前只要部署一个war包，现在可能需要部署成百上千war包 (k8s+docker+jenkins )
- 服务之间相互调用，增加通信成本
- 数据一致性问题(分布式事务问题)
- 性能监控等,问题定位
微服务的适用场景
合适
- 大型复杂的项目............(来自单体架构200W行代码的恐惧)
- 快速迭代的项目............(来自一天一版的恐惧)
- 并发高的项目................(考虑弹性伸缩扩容的恐惧)
不合适
- 业务稳定，就是修修bug ，改改数据
- 迭代周期长 发版频率 一二个月一次
微服务架构
微服务架构风格是一种将单个应用程序作为一套小型服务开发的方法，每种应用程序都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）进行通信。 这些服务是围绕业务功能构建的，可以通过全自动部署机制独立部署。 这些服务的集中管理最少，可以用不同的编程语言编写，并使用不同的数据存储技术。
SOA架构强调的是异构系统之间的通信和解耦合，而微服务架构强调的是系统按业务边界做细粒度的拆分和部署
微服务架构是一个架构风格, 提倡:
- 将一个单一应用程序开发为一组小型服务.
- 每个服务运行在自己的进程中
- 服务之间通过轻量级的通信机制(http rest api)
- 每个服务都能够独立的部署
- 每个服务甚至可以拥有自己的数据库
微服务以及微服务架构的是两个完全不同的概念。微服务强调的是服务的大小和对外提供的单一功能，而微服务架构是指把 一个一个的微服务组合管理起来，对外提供一套完整的服务
Spring Cloud 微服务技术栈
Spring Cloud是分布式微服务架构的一站式解决方案，是多种微服务架构落地技术的集合体，俗称微服务全家桶。 为开发人员提供了快速构建分布式系统中的一些常见模式的工具(例如配置管理、服务发现、断路器、智能路由、微代理、 控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态)。
访问地址
官网： https://spring.io/projects/spring-cloud
中文文档： https://www.springcloud.cc/
Spring Cloud中国社区：http://springcloud.cn/
Spring Cloud Netflix
相关组件
- Eureka:服务注册和发现，它提供了一个服务注册中心、服务发现的客户端，还有一个方便的查看所有注册的服务的界面。 所有的服务使用Eureka的服务发现客户端来将自己注册到Eureka的服务器上。
- Zuul:网关，所有的客户端请求通过这个网关访问后台的服务。他可以使用一定的路由配置来判断某一个URL由哪个服务来处理。并从Eureka获取注册的服务来转发请求。
- Ribbon:即负载均衡，Zuul网关将一个请求发送给某一个服务的应用的时候，如果一个服务启动了多个实例，就会通过Ribbon来通过一定的负载均衡策略来发送给某一个服务实例。
- Feign:服务客户端，服务之间如果需要相互访问，可以使用RestTemplate，也可以使用Feign客户端访问。它默认会使用Ribbon来实现负载均衡。
- Hystrix:监控和断路器。我们只需要在服务接口上添加Hystrix标签，就可以实现对这个接口的监控和断路器功能。
- Hystrix Dashboard:监控面板，他提供了一个界面，可以监控各个服务上的服务调用所消耗的时间等。
- Turbine:监控聚合，使用Hystrix监控，我们需要打开每一个服务实例的监控信息来查看。而Turbine可以帮助我们把所有的服务实例的监控信息聚合到一个地方统一查看。这样就不需要挨个打开一个个的页面一个个查看
Spring Cloud Alibaba技术栈
同 Spring Cloud 一样，Spring Cloud Alibaba 也是一套微服务解决方案，包含开发分布式应用微服务的必需组件，方便开发者通过Spring Cloud 编程模型轻松使用这些组件来开发分布式应用服务。
依托 Spring Cloud Alibaba，您只需要添加一些注解和少量配置，就可以将 Spring Cloud 应用接入阿里微服务解决方案，通过阿里中间件来迅速搭建分布式应用系统。
作为 Spring Cloud 体系下的新实现，Spring Cloud Alibaba 跟官方的组件或其它的第三方实现如 Netflix, Consul，Zookeeper 等对比，具备了更多的功能:
包含组件
阿里开源组件
- Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
- Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
- RocketMQ：开源的分布式消息系统，基于高可用分布式集群技术，提供低延时的、高可靠的消息发布与订阅服务。
- Dubbo：在国内应用非常广泛的一款高性能 Java RPC 框架。
- Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
- Arthas：开源的Java动态追踪工具，基于字节码增强技术，功能非常强大。
阿里商业化组件
作为一家商业公司，阿里巴巴推出 Spring Cloud Alibaba，很大程度上市希望通过抢占开发者生态，来帮助推广自家的云产品。
- Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
- Alibaba Cloud OSS：阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的云存储服务。
- Alibaba Cloud SchedulerX：阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准的定时（基于 Cron 表达式）任务调度服务。
版本选择
推荐使用
2.2.5版本使用
各个组件及SpringBoot版本对应关系
Nacos使用
Nacos架构
NamingService: 命名服务，注册中心核心接口
ConfigService：配置服务，配置中心核心接口
OpenAPI文档：Open API 指南
官方文档： https://nacos.io/zh-cn/docs/what-is-nacos.html
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态
服务发现、服务配置、服务元数据及流量管理。
Nacos 的关键特性包括:
- 服务发现和服务健康监测
- 动态配置服务
- 动态 DNS 服务
- 服务及其元数据管理
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秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)
服务注册表
服务实例数据
http://localhost:8848/nacos/v1/ns/instance/list?serviceName=mall-order
