SpringCloud - 微服务架构

单体应用

单体应用的优点
开发简单：方便开发
便于共享：单个归档文件中包含所有的功能，便于在团队之间以及不同的部署环境阶段进行共享
易于测试：测试便捷，部署方便

单体应用的缺点
复杂性高:所有功能都在一个应用中，耦合度比较高
技术债务：单体应用所用的技术都特别单一，所以市场上的一些中间件，新技术无法应用到单体应用上

面向接口编程

SOA多业务架构

面向服务架构
它一种设计方法, 服务之间通过相互依赖最终异同一系列的功能,一个服务通常以独立的形式存在.

微服务架构

微服务的特点
面向服务
松耦合
模块化
分布式计算
平台无关
集中管理

微服务的优点
开发简单
技术栈灵活
各服务之间没有任何依赖关系
独立性强,可以按需拓展
可用性比较高

微服务的缺点
维护成本高
运维难度大
复杂
数据一致性差
重复工作
性能监控不及时
通信复杂

我们什么时候需要使用微服务

1.开发效率非常快的情况下需要:
应用进行微服务化后,规模和体积将边的非常轻量, 在编译,打包,分发,部署等环境都节约了大量的时间,开发效率明显提升
2. 保证质量时需要:
微服务应用面向持续集成,友好度比较高, 自动化编译,单元和集成测试用例的执行和回归,提高应用的整理质量时需要用到微服务
3. 稳定的时候需要
单体应用是牵一发动全身,微服务,牵一发,动一动 ,在微服务中,单一功能挂掉之后,不影响其他功能

我们什么时候不需要使用微服务
1.场景单一
应用只有几个特定的功能, 没有必要进行微服务独立开发时
2. 逻辑简单
…
当单体应用的一个功能挂掉后,这个单体应用就无法使用了 ( 修改代码后重新部署 )

当微服务的一个功能挂掉后,这个功能牵连的功能无法使用外,其他的功能影响正常功能(正常生产) ( 服务检测, 重试机制,限流,熔断机制,(客户端)负载均衡, 降级)

springcloud的生态图谱

绿色部分为常用组件
Eureka:
服务注册与发现，各个服务启动时，Eureka Client都会将服务注册到Eureka
Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道
其他服务在哪里
Ribbon:
服务请求调用客户端负载均衡，服务间发起请求的时候，基于Ribbon做负载均衡，
从一个服务的多台机器中选择一台
Feign:
服务请求调用，基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL
地址，发起请求
Hystrix:
熔断器，发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实
现了不同服务调用的隔离，避免了服务雪崩的问题
Zuul:
api路由网关，如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网
关转发请求给对应的服务
gateWay:
zuul替代品