微服务架构
（一）什么是微服务，为什么需要用微服务？
一、微服务是什么？
定义：微服务是一些协同工作的小而自治的服务，这个服务是高凝聚力和松散耦合的。
微服务有以下特征：
1.一组小的服务（大写没有特别的标准，只要同一个团队的工程师理解服务的标识一致即可）。
2.独立的进程
3.轻量级的通信（不是soap,是http协议）
4.基于业务能力
5.独立部署（迭代速度快）
6.无集中式管理（无须统一技术栈）
二、为什么要用微服务？
通常我们把微服务说成是一个技术架构的进化，从第一代的单体架构，到期第二代SOA架构，第三代微服务架构。
第三代的出现，一定是为了解决第一代和第二代的不足之处的：
第一代的主要问题：太过耦合，部署成本过高（修改一行，均要全部改），重复做轮子，完全封闭的架构。
第二代的主要问题：ESB总线进行集成，扩容困难，集中式的。
第三代：松散耦合，专注某个业务的小团队（2个比萨的成员数），升级按天/周进行发布，全自动化，扩展弹性，高可用。
三、微服务特点及价值：
价值：（1） 高频发布或升级 （2）可复用 （3）分布式易扩容，满足高并发需求。
特点：一句“高凝聚力和松散耦合”。
特点解释：（1）专注某个业务 （2）自治性 （3）它是一个独立的实体 （4）对微服务有专门的划分原则及治理技术手段，避免把多个服务部署在同一台机器。
（二）对于业务如何划分微服务，即微服务的颗粒度，又称业务边界
写在前面的一句话：使用微服务架构的大型软件公司，都是从使用一体化应用程序开始的。一旦它们达到了可扩展性和可维护性的极限，它们就会将一体化机器分解为独立的部件或服务。
微服务的划分是一个难点，如何处理好：(1)微服务不能太大，也不能太小 (2) 紧密耦合程度如何把握？
微服务颗粒度划分与设计原则：
一、业务原则：
1. 这个微服务不会与其他的服务共享数据库表，注意是表，不是库,即避免多个微服务引用同一个表的服务，如果有他们均属于同一个微服务。
2.这个微服务具有最少量的数据库表：这个表尽量少，这个可能要看业务需求，不是绝对。
3.这个微服务可能是有状态（即和数据库有关），或者无状态（即非数据库）的。
4.单一责任原则，又称这是一个真理的单一来源，即这个服务是系统中某一件事的唯一真理来源，即这个微服务在整个系统中代表功能的唯一性，它具有时空不变性的特质，同时满足有限业务范围内进行设计，从而实现交付的敏捷。
5.微服务颗粒度与2个披萨的关系：你有几个2 pizza团队，最好就拆成几个微服务，只有一个开发人员时尽量做单体应用，不要没事找事找刺激拆成10个微服务，最终这个开发人员还会把他合成一个。
微服务的本质就是团队的分工，微服务要求纵向的2 pizza团队（7，8个人以内）（无数个小团队，包含开发、测试、运维）。
坚持以康威定律作为指导思想。
6.微服务从业务层面分为核心业务和非核心业务，要紧持业务与技术分离后，把参与者与一个或者多个业务原子行为组合在一起就形成了微服务。
7.适当的边界：关注微服务的功能范围，一个服务的大小应该等于满足某个特定业务能力所需要的大小；
8.非唯一性依赖：至少被2个以上其它微服务依赖的功能模块，才有必要独立成一个微服务
总结：拆分的粒度太细和太粗都是不合理的，根据业务需要，能够满足上层服务对底层服务自由编排并获得更多的业务功能即可，并需要适合团队的建设和布局。因此，这里倡导对微服务的拆分适可而止，原则是拆分到可以让使用方自由地编排底层的子服务来获得相应的组合服务即可，同时要考虑团队的建设及人员的数量和分配等。
二、技术原则：
1.部署独立性
2.动态扩展、
3.避免产生频敏的跨库查询
4.避免产生频繁的分布式事务。
三、治理原则：
1.在业务分层的基础上，根据业务细分规则，对微服务分组；
2.各个分组之间通过API网关集成；
3.通过API网关实现级轻量级消息路由，鉴权；
4.运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；
5.避免通过数据库集成；
6.避免部署多个版本来兼容。
四、微服务设计发展的一个思想趋势：
前台UI遵循以用户为中心的设计思想。以用户为中心的设计就是完全站在用户的角度来思考前台UI的设计，使用清晰合理的界面逻辑来帮助用户达成目标。前台UI应该尽可能的轻，这样才能够快速地去适配不同用户的不同需求。
后台微服务遵循以业务为中心的设计思想。以业务为中心的设计就是完全站在业务处理的角度来思考微服务的设计，需要考虑业务处理的各种场景，使用合理的设计达到微服务之间的隔离性高，扩展性好等目标。因为业务领域的东西不会经常变化，并且随着市场的发展对于服务的需求量可能会呈现指数级的增加，所以后台服务应该尽可能地保持稳定和维持很好的扩展性，这样整个微服务集群才能够向外稳定地提供服务。
服务中台遵循以用户为中心的流程来驱动微服务之间的协作的设计思想。服务中台起到协调前台UI和后台微服务之间的作用，针对不同用户的不同处理流程，可以驱动不同的微服务之间进行协作，从而满足不同的业务处理需求的目的。服务中台应该尽可能地强大，这样才能够应付用户的各种不同的业务处理需求。
（三）Spring Cloud Netflix 和Spring Cloud alibaba服务技术架构
一、Spring Cloud Netflix 和Spring Cloud alibaba服务技术架构比较
二、重点介绍Spring Cloud alibaba微服务一站式解决方案
Spring Cloud 本身其实只是一套微服务规范，并不是一个拿来即可用的框架，Spring Cloud Netflix 和Spring Cloud alibaba是为开发者提供了这套规范的实现方式。由于Spring Cloud Netflix 2018年12月12日进入维护模式（Maintenance Mode），所以不太适合长期再使用。故选择Spring Cloud alibaba的技术方案。
2019年7月24日Spring官方社区官方博文中宣布了Spring Cloud Alibaba正式从 Spring Cloud Incubator 孵化器毕业，成为了Spring社区的正式项目。同时国内版Github码云也提供了Spring Cloud Alibaba极速下载镜像。
三、Spring Cloud alibaba 技术架构
四、Spring Cloud alibaba 主要功能及对应组件
(一）服务的注册与发现(对标Netflix的Eureka译音尤利卡)： Nacos
（二）负载均衡Ribbo
（三）声明式HTTP客户端Feign
(四）服务容错Sentinel
(五）消息驱动RocketMQ
(六）API网关GateWay( 可以集成开源的Soul网关或者 spring Cloud Gateway）
(七）配置管理Nacos
(八）调用链监控Sleuth
(九）服务限流降级（即熔断限流，对标Hystrix）：Sentinel：把流量作为切入点，从流量控制、熔断降级、系统负载保护等多个维度保护服务的稳定性。
（十）分布式配置管理：Alibaba Cloud ACM：一款在分布式架构环境中对应用配置进行集中管理和推送的应用配置中心产品。
（十一）分布式事务： Seata：阿里巴巴开源产品，一个易于使用的高性能微服务分布式事务解决方案。
（十二）阿里云对象存储（收费）： Alibaba Cloud OSS: 阿里云对象存储服务（Object Storage Service，简称 OSS），是阿里云提供的海量、安全、低成本、高可靠的云存储服务
（十三）分布式任务调度（收费）：Alibaba Cloud SchedulerX: 阿里中间件团队开发的一款分布式任务调度产品，提供秒级、精准、高可靠、高可用的定时（基于 Cron 表达式）任务调度服务。
（十四）阿里云短信服务（收费）：Alibaba Cloud SMS: 覆盖全球的短信服务，友好、高效、智能的互联化通讯能力，帮助企业迅速搭建客户触达通道。
（十五）用户认证与授权
（四）spring cloud alibaba -nacos深入研究
一、nacos是什么？
微服务的注册、发现及配置中心，即微服务的大脑，它有几个关键特性：微服务的注册、服务的发现（nacos支持DNS和基于RPC的服务发现）、动态的配置。
一句总结：帮助我们发现、配置和管理微服务。
二、nacos的功能
(一）微服务的注册
服务端可以通过SDK或者Api进行服务注册，相应的服务消费者可以使用DNS或者Http查找的方式获取服务列表。
服务提供者：nacos-provider
服务消费者：nacos-consumer
注册中心：Nacos-server
将服务者和消费者均要注册到Nacos-server，服务消费者nacos-consumer通过主动轮询获取他所订阅消费的服务信息列表，然进行服务调用。
（二）微服务的发现
（三）微服务的健康检测
三、nacos的安装与使用（以下为二进制的部署方式，同时支持Docker和K8s的部署）
按需求不一样，又分为：单机部署（内存模式），单机部署（Mysql模式），集群部署。
1.下载地址： https://github.com/alibaba/nacos/releases
2.下载解压后进入bin文件夹（目录：nacos-server-1.0.1\nacos\bin），直接双击执行startup.cmd文件，缺省端口8848（即珠峰高度）
3.启动成功后，此时Nacos控制台就可以访问了，浏览器访问：http://127.0.0.1:8848/nacos/index.html ，默认的账号密码为nacos/nacos，控制台页面如下：
3.idea中去开发微服务提供者和消费者。
四、Nacos的几个基础概念：
endpoint： 物理隔离，例如生产环境和开发环境运行的是不同的设备。
namespace 命名空间(即顶级目录）：用来区分不同的项目，同一个设备上通过某一个字段为区分。
Group 配置集分组：同一个项目，不同的模块需要隔离，软隔离,也是为了避免DataID不重命名。
DataID 配置集：DataID为区分不同的配置项。
（五）微服务之间调用的两种方式：RPC方式和事件驱动（event-driven)方式
微服务中经常会采用，技术上选择事件驱动，业务上讲是RPC模式。事件通知作为微服务的集成方式，应用越来越广。
一、RPC方式（紧耦合）：
点对点的远程函数标签模式，实时返回值，常见RESTFul,gRPC,Dubbo都是这种方式，同步的。
二、事件驱动方式（松耦合），即消息模式
事件驱动分为：事件通知和事件溯源，事件通知应用的比较多，事件溯原应用很少的应用。
现在大量出现的消息队列产品，例如：ActiveMQ,RabbitMQ,RocketMQ/Kafka。
（六）一个产品需要多少数量的微服务是合理的？一个微服务多少数据库表是合理的？
一、概述
微服务技术的出现，不是技术的创新，而是满足管理需要。主要目的解决单体程序由于过大，造成了组织开发，部署运维工作无法协调，主要问题就是：不同的模块可能上线的时间节点不一样，对服务器的优化要求也不一样,团队人员太多，如何高效组织与集成。
微服务出现后，一个团队负责一个或者几个微服务，这样管理就轻松了，但带来的问题就是产品的发布与运维带来的新的麻烦，不过全套的自动化体系，从程序集成到部署，从全路链跟踪到日志，以及服务检测，服务发现和注册，解决了运维工作量很大这个问题。
二、一个公司或者一个产品一般约定多少微服务：十几个或者几十个，但不能超100个。
三、一个微服务对应多少数据库表？
一个微服务尽量不要超过10张数据库表。当然为了减少微服务的数量，也可以微服务弄大一些，即一个微服务不要超过20张表。
（七）规模不大的单体程序推荐也用微服务技术这是一个趋势---单体内部微服务设计方案
前言：
微服务技术要不要用，由以下产品决定的：
（1）必须用：单体程序团队太大了，没法管理，所以一开始就规划好，每个团队负责几个微服务。
（2）变通用：可能只有一个团队，没有几个人，又想未来单体能拆出来形成一个个微服务，前期按单体应用来开发，这时候就是前期设计思想采用了微服务技术来设计，但开发，运维更象还是单体应用开发，后面没法管理时，把原来逻辑设计好的模块独立出来就形成了一个个微服务。
一、什么叫内部微服务设计？
这种设计表面上看起来是一个单体程序，它只有一个源代码存储仓库，一个数据库，一个部署，但在程序内部可以按照微服务的思想来进行设计。它可以分成多个模块，每个模块是一个微服务，可以由不同的团队管理。
二、内部微服务的思想是什么？
一个单体程序由 各个模块组件构成，每一个模块就是一个微服务，它可以由不同的团队来开发与管理。
一个模块未来就是可能独立抽出来的单体程序形成一个微服务，每一个模块都有自己的一套数据库表，但模块之间不能跨数据库访问（不要建立模块之间数据库表的外键）。
多个模块之间有共享的实体类，根据DDD的上下文约定原则，不建议共享，虽然数据大致相同，应在不同的模块中采用不同的名字。
内部微服务，说白了就是用DDD，注重业务逻辑上的设计。
三、内部微服务特点：
这样设计的好处是它是一个单体程序，省去了多个微服务带来的部署、运维的麻烦。但它内部是按微服务设计的，如果以后要拆分成微服务会比较容易。至于什么时候拆分不是一个技术问题。
四、何时把它独立出来，形成真正的微服务？
如果负责这个单体程序的各个团队之间不能在部署时间表，服务器优化等方面达成一致，那么就需要拆分了。
当然你也要应对随之而来的各种运维麻烦。内部微服务设计是一个折中的方案，如果你想试水微服务，但又不愿意冒太大风险时，这是一个不错的选择。
（八）nacos下载与安装配置
一、前提
(1)下载nacos, 下载地址：https://github.com/alibaba/nacos/releases
(2) 可以使用它自带的数据库内嵌的cmdb（则不需要任何配置），或者另外安装mysql8.0及对应的数据库驱动，并且导入nacos数据库脚本(/nacos/conf/application.properties)。
spring.datasource.platform=mysql
### Count of DB:
db.num=1
### Connect URL of DB:
db.url.0=jdbc:mysql://1.1.1.1:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true
db.user=user
db.password=password
cmd startup.cmd 或者双击startup.cmd运行文件。
(3)访问：127.0.0.1:8848/nacos/index.html 出现登录界面，启动成功。（用户名和秘密都是nacos）。
(4) 修改默认的账户账号和密码：
a. 创建一个spring boot，在它的pom.xml加入以下一段：
b.然后写个类执行以下 new BCryptPasswordEncoder().encode("你的密码")就会生成新的加密过的密码。
import org.springframework.security.crypto.bcrypt.BCryptPasswordEncoder;
public class Main {undefined
public static void main(String[] args) {undefined
System.out.println(new BCryptPasswordEncoder().encode("nelson$nacos"));
}
}
c.接下来就是复制密码去数据库替换默认的密码。默认用户是nacos 也可以修改，那个是明文的可以直接改，但是如果要修改用户名的话，要修改roles表里用户。
d.nacos本身里面的conf/application.properties配置文件，将应用端口改为8001（和之前的febs-register端口一致）：
server.port=8001
（九）spring boot如何满足nacos的要求，即自动注册到nacos中的服务中。
一、第一种配置法，spring boot中写死nacos的ip及端口的方案：
（一）spring boot的pom.xml中配置spring cloud alibaba
(二）application定义nacos 注册服务器的ip地址和端口
server:
port: 8060
spring:
application:
name: power-match #项目名
profiles:
active: local
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848 #注册中心地址
discovery:
server-addr: 127.0.0.1:8848
(三）spring boot启动类中增加如下（使用了feign)
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.discovery.EnableDiscoveryClient;
import org.springframework.cloud.openfeign.EnableFeignClients;
@EnableFeignClients
@EnableDiscoveryClient
@SpringBootApplication
public class PowerMatchApplication {undefined
public static void main(String[] args) {undefined
SpringApplication.run(PowerMatchApplication.class, args);
}
}
二、第二种方案（官方推荐）：分环境来配置
还是同一个nacos，登录——找到命名空间——新建命名空间，输入内容后就会生成命名空间ID
以application-local.yml配置为例：
spring:
cloud:
nacos:
config:
namespace: e503611c-9c54-4669-baff-e12770b3e948
discovery:
namespace: e503611c-9c54-4669-baff-e12770b3e948
ribbon:
ReadTimeout: 60000
ConnectTimeout: 60000
启动后，去看服务列表的test下面就有注册的服务了，只会服务调用就会只在local中调用。