SpringBoot 自动配置、依赖注入

SpringBoot通过自动配置、依赖注入的方式解决了Java对第三方包的管理，后者降低了类互相依赖的耦合性。

配置

SpringBoot基于约定，有很多默认配置值，需要修改则要使用约定好的名称并写上想要设定的值。
application.properties：

server.port=8080

application.yml/application.yaml：

server:
  port: 8080

三个配置文件都存在时，以properties中的设定为最优先级

单体部署灵活，每个服务应用都是独立部署，耦合性低，可以轻松完成分布式和增减服务
降低启动难度和宕机危害
不同项目技术可选，相比单体应用项目几乎只能整体搬迁到新技术栈而代码量庞大费时费力不一定有完美兼容实现，而微服务中不同服务项目可以容许使用不同技术栈和因为代码量少而轻松完成搬迁到新技术栈
不同人员配置，可以容许不同团队维护不同的服务项目，但依旧需要在接口调用上保持可靠。
额外的复杂度，因为这种分布式导致各种网络、负载、并发、事务问题更突出，提高了测试、整体部署和运维难度。

注册服务，统一的配置中心，微服务启动后会在这里注册成为可用的服务，需要调用服务的程序也会在这里寻找调度可用服务
RPC，即远程调用(Remote Process Call)，相比HTTP请求更下一层使用TCP请求，以达成双向即时响应和更快速
gRPC，谷歌实现的一套基于RPC的通用框架，在不同场景采用不同技术实现，如操作系统采用C++实现服务端，后端程序Java、Nodejs使用SDK（底层调用C++）调用，浏览器使用js库（内部采用WebSocket）调用。
雪崩，某服务不可用后还出现大量请求导致所有关联服务都被拖垮
削峰，对于超过设定的并发量（服务最高承载量）后，对超额请求直接返回失败或放入延时等待队列中
限流，对单个服务请求设定限制单位时间内访问次数（如用计数器、令牌桶、漏桶和客户端验证码防刷），一般配合削峰使用
熔断，对于超过一定失败率的相同请求在一段时间内都直接返回失败
降级，对于超负荷/响应速度慢时，让非必要性服务请求放到延时等待队列中，请求本身状态变为处理中即可，让关键服务请求可以有更好的流量和响应速度

Eureka/Nacos，服务注册与发现，保存微服务的ip地址、端口号、版本号、通信协议等，使用双层Map对应服务名、实例名和实际内容，并维持心跳包和剔除无用服务，若是集群则需要保持实例保持一样。
Ribbon，请求负载均衡，根据所写的服务接口请求去Eureka里寻找合适的服务实例并发起请求
Feign/OpenFeign/Dubbo，将代码调用映射成服务接口请求，不需要自己手动按要求写一堆请求，而是像调用项目内代码一样通过Ribbon负载均衡后远程调用微服务。
Hystrix/Sentinel，线程池实现服务调用隔离，并完成服务限流、熔断、降级
Zuul/Kong/SpringCloudGateway，服务网关，过滤请求和验证权限并执行实际的请求操作
Seata：分布式事务

Spring Cloud 是全面型的微服务框架，Dubbo核心是远程调用框架，因为性能好，一般会引入Dubbo结合Spring Cloud一起使用。

举例讲，按照领域拆分所有模块和服务，例如物流服务关注产品的规格、体积、重量等，而订单服务关注产品的规格、价格等，无论两者关注的产品本身是不是同一张表，但服务领域是分离的，各自只关注自己需要的属性，两者的联系从单体应用开始就需要尽可能分离，之后才容易改进成微服务。

中台的概念即是将各种通用的部分抽取出来作为一个中间层，开发任意项目时都能直接调用中台完成业务处理和数据存储，而项目本身只需要集中开发特化的部分。
中台和微服务一样，都是受DDD设计规范影响而做的战略战术设计。

按Controller-Service-Dao，直接按此结构分成三个逐层依赖的模块，优点是从原有单一应用变更到这种方式非常容易，缺点是没有很好的体现微服务要达成的目标，耦合性与原本没有区别。
按功能性划分，例如用户、订单、内容、商品，但有可能功能模块之间关联性过强的话，这种分离也只适用于单一复杂度高的项目。
按DDD划分，按照DDD设计规范先把功能按照这种方式分离，之后做成对应的服务。中台项目或者多应用项目一般采用这种方式
按照开发用途划分，例如分成核心、系统管理、前台展示、第三方API、工具包等，方便用户对其进行二次开发，开源项目一般也是采用这种方式。

跨语言本应该是微服务的优势之一，即不同的领域服务可以选择适合的开发语言去开发实现，但同时这也要求在有统一的注册中心/配置中心后，其他开发语言里对应也需要实现一些相应的适配如心跳、注册服务、本地调用转远程调用才能让不同服务之间互相调用起来显得顺畅。

其中thrift已经实现了大部分语言如java、.net、C++、nodejs、python、php、rust等一定程度的兼容，但只实现了远程调用，没有实现配置中心和注册中心的功能。
thrift

而像dubbo则是支持配置中心和注册中心，但只做了java、nodejs的实现，不支持.net、C++等开发语言。如果想兼容其他语言还得自己参考源码开发。
异构SOA系统架构之Asp.net实现(兼容dubbo)