|
@ -29,6 +29,30 @@ pivotal 是云原生应用的提出者,可以说是云原生的先驱或探路 |
|
|
|
|
|
|
|
|
最新定义里面容器和微服务都提到了,服务网格是提到了和微服务、容器 并列,和我们理解的是微服务的一种实现有所不同。 |
|
|
最新定义里面容器和微服务都提到了,服务网格是提到了和微服务、容器 并列,和我们理解的是微服务的一种实现有所不同。 |
|
|
|
|
|
|
|
|
|
|
|
cncf 的 [cloud native landscape](landscape.pdf) |
|
|
|
|
|
|
|
|
|
|
|
- 自动化、配置中心 |
|
|
|
|
|
- 容器管理 |
|
|
|
|
|
- 容器编排 |
|
|
|
|
|
- 协同、服务发现 |
|
|
|
|
|
- 远程调用 |
|
|
|
|
|
- API 服务网关 |
|
|
|
|
|
- 服务网格 |
|
|
|
|
|
- 监控、日志、链路跟踪 |
|
|
|
|
|
- 数据库 |
|
|
|
|
|
- 流和消息处理 |
|
|
|
|
|
- 应用开发、镜像构建和持续集成 |
|
|
|
|
|
- 云原生存储 |
|
|
|
|
|
- 平台管理 |
|
|
|
|
|
- ... |
|
|
|
|
|
- ... |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
--- |
|
|
--- |
|
|
|
|
|
|
|
|
> 云原生自身的定义一直在变,这让我们该如何才能准确的理解云原生呢? |
|
|
> 云原生自身的定义一直在变,这让我们该如何才能准确的理解云原生呢? |
|
@ -65,11 +89,10 @@ pivotal 是云原生应用的提出者,可以说是云原生的先驱或探路 |
|
|
|
|
|
|
|
|
- **k8s** |
|
|
- **k8s** |
|
|
|
|
|
|
|
|
- 微服务/服务网格 |
|
|
- 微服务/==服务网格== |
|
|
|
|
|
|
|
|
## 如何让自己的应用符合云原生 |
|
|
## 如何让自己的应用符合云原生 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
在云原生之前,底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求,为了更好的代码复用,通用型好的非业务需求的实现往往会以类库和开发框架的方式提供,另外在 SOA/微服务时代部分功能会以后端服务的方式存在,这样在应用中就被简化为对其客户端的调用代码。 |
|
|
在云原生之前,底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求,为了更好的代码复用,通用型好的非业务需求的实现往往会以类库和开发框架的方式提供,另外在 SOA/微服务时代部分功能会以后端服务的方式存在,这样在应用中就被简化为对其客户端的调用代码。 |
|
|
然后应用将这些功能,连同自身的业务实现代码,一起打包 |
|
|
然后应用将这些功能,连同自身的业务实现代码,一起打包 |
|
|
|
|
|
|
|
@ -95,9 +118,67 @@ pivotal 是云原生应用的提出者,可以说是云原生的先驱或探路 |
|
|
> - 基础设施 |
|
|
> - 基础设施 |
|
|
> - 下沉到基础设施 |
|
|
> - 下沉到基础设施 |
|
|
|
|
|
|
|
|
|
|
|
#### 轻量化 |
|
|
|
|
|
|
|
|
|
|
|
> 体积小,启动快、占用资源少 |
|
|
|
|
|
|
|
|
|
|
|
- java |
|
|
|
|
|
- spring |
|
|
|
|
|
|
|
|
|
|
|
> `GraalVM` 编译器 |
|
|
|
|
|
|
|
|
|
|
|
微服务:可扩展性、可升级、`易于维护?`、故障和资源隔离。 |
|
|
|
|
|
|
|
|
|
|
|
- 服务治理 :弹性收缩、故障隔离 |
|
|
|
|
|
- 流量控制 :路由、熔断、限流 |
|
|
|
|
|
- 应用可观测 :监控指标、故障追踪 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
spring cloud:提供了服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等核心功能,一度是微服务的不二选择 |
|
|
|
|
|
|
|
|
|
|
|
问题:。。 |
|
|
|
|
|
|
|
|
|
|
|
侵入性强 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
k8s具备完善的集群管理能力,包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。还提供完善的管理工具,涵盖开发、部署测试、运维监控等各个环节。可以说基础设施上已经提供比较齐全的功能。 |
|
|
|
|
|
|
|
|
|
|
|
还有必要使用 spring cloud 自带的组件吗?? |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
spring native / spring one |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
当然这里并不是说,面向服务的架构已经过时,事实上面向服务的架构非常成功,但是在云原生或 `Serverless`环境下,可能事件驱动架构可能更合理一些,或者是两者的配合使用 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
> Logstash pk Filebeat |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Linkerd-proxy pk envoy |
|
|
|
|
|
|
|
|
|
|
|
```flow |
|
|
|
|
|
op1=>operation: Linkerd-proxy |
|
|
|
|
|
op2=>operation: Linkerd2-proxy |
|
|
|
|
|
|
|
|
|
|
|
op1->op2 |
|
|
|
|
|
``` |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
#### Service Mesh |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Service Mesh |
|
|
|
|
|
|
|
|
|
|
|
![](http://resources.lingwenlong.com/note-img/20210901003427.png) |
|
|
![](http://resources.lingwenlong.com/note-img/20210901003427.png) |
|
|
|
|
|
|
|
|