Browse Source

changed cloud native

master
uncle dragon 3 years ago
parent
commit
4785774d1c
  1. 1
      SUMMARY.md
  2. 87
      k8s&container/cloud-native.md
  3. BIN
      k8s&container/cloud-native.pdf
  4. BIN
      k8s&container/landscape.pdf

1
SUMMARY.md

@ -35,6 +35,7 @@
- [Docker 官方文档](https://docs.docker.com/reference/) - [Docker 官方文档](https://docs.docker.com/reference/)
- [阿里k8s 项目实战手册](k8s&container/ali-kubernetes.pdf) - [阿里k8s 项目实战手册](k8s&container/ali-kubernetes.pdf)
- [Kubernetes 文档 ](https://kubernetes.io/zh/docs/home/) - [Kubernetes 文档 ](https://kubernetes.io/zh/docs/home/)
- [云原生介绍](k8s&container/cloud-native.pdf)
- [wsl2 安装和配置优化](k8s&container/WSL2-start.pdf) - [wsl2 安装和配置优化](k8s&container/WSL2-start.pdf)
- [基于WSL2和vscode搭建nodejs linux 开发环境](k8s&container/基于WSL2和vscode搭建nodejs%20linux%20开发环境.pdf) - [基于WSL2和vscode搭建nodejs linux 开发环境](k8s&container/基于WSL2和vscode搭建nodejs%20linux%20开发环境.pdf)
- [k8s dcoker 的恩怨纠葛](k8s&container/containerd-k8s.pdf) - [k8s dcoker 的恩怨纠葛](k8s&container/containerd-k8s.pdf)

87
k8s&container/cloud-native.md

@ -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)

BIN
k8s&container/cloud-native.pdf

Binary file not shown.

BIN
k8s&container/landscape.pdf

Binary file not shown.
Loading…
Cancel
Save