search

timzaak / blog

8 stars 1 forks source link

微服务一点小思考 #17

Closed timzaak closed 5 years ago

timzaak commented 6 years ago

为什么需要微服务：

  1. 某些特定需求当前项目选型无法满足，例如 java 项目中的一些算法需要加密，即使混淆也不好处理。
  2. 根据成员结构，进行拆分项目，以便各自更高效的开发
  3. 程序中的某一块，对特定资源依赖严重，拆分出去。方便提升硬件利用率
  4. 核心程序，对它人保密

微服务会遇到那些坑：

1. 微服务之间代码如何复用

git submodule 解决复用问题

2. RPC（请求链路）如何跟踪

引入第三方框架

3. 服务发现

docker cluster 基本满足

4. 自动化部署

ci 环境搭建好后，通过 jenkins

5. 配置集中管理

consul 统一管理+ 实时备份 （缺乏层级嵌套功能） 目前没有好的方案。开源的都没怎么尝试。 应该支持三个点：

  1. 配置可嵌套覆盖 2.配置变化可通知 3.权限系统

    6. 集群监控

    Promethues + Grafana 等

如果可以，最好不要用微服务！微服务的成本并不低。虽然 docker 已经帮忙解决了不少东西。 另外，微服务，应该是自然而然演变的，从一个项目中，先隔离代码，将代码隔离完毕后，再拆编译脚本，然后再拆项目。

RPC（请求链路）如何跟踪 和 服务发现 可以使用 Service Mesh 来解决。目前有两个方案

  1. Linkerd2
  2. Istio 但这两个目前都是命令行操作，通过命令行往 yml文件 注入配置，目前还没有比较好用的UI界面操作
timzaak commented 6 years ago

docker swarm 目前已经将所有必须的都集成了。除了监控。不需要搞很多东西。

最新的消息是 k8s 已经要被 docker 官方集成了。另外貌似国内很多大型公司都在向 k8s 转型。观望中...

timzaak commented 6 years ago

istio 这个微服务治理工具，需要列入观察范围了

timzaak commented 6 years ago

在陆陆续续学习了这么长时间后，内心对微服务有了新的理解。记录出来。 现在基于容器技术出来的服务治理，无外乎3个东西，也就是 k8s 的三层抽象：

  1. CRI - Container Runtime Interface
  2. CNI - Container Network Interface
  3. CSI - Container Storage Interface

CRI 就是管理容器的生死； CNI 就是让容器之间，能方便的找到对方；CSI 则是持久化存储。 现在 CRI 拓展成了：微服务组装，快速扩容，优雅升级、回滚... CNI： 网络监控，调用链回溯，DNS路由... CSI： 分布式存储、按需存储...

CNI 则越来越成熟，SideCar 概念应运而生。以前 Netflix、Spring Cloud 的一套可以越来越不用太关心，技术异构选型也更容易一些，技术分工也能往更深处走。 This is wonderful！

而 CSI，目前除了 Ceph 块存储外，还不太知道有什么更成熟的技术，期望云厂商能开发出简便易用的 CSI 出来。当然也可以用 NFS 顶着。

timzaak commented 5 years ago

最近试验k8s，感觉除了权限，namespace域外，其复杂度以及对资源的需求超过了小型微服务架构的需求，故目前暂停观察。由此导致这 istio 和 linkerd2 也陷入停滞（两个目前主要支持k8s，istio 还支持 consul 那一套生态）。 所以我的核心还是放在 rancher 1.6 上。 本着在 rancher1.6上搞 service mesh 的目的，又调研了一遍 envoy，发现其 xDS 辅助工具官方只有个 go-control-plane 简单版， Huston 又是商业版，另外未找到监控相关的集成。 在调研中，对 service mesh 更新了一个幼稚的认知：

本以为 service mesh 会从网卡方面入手, 接管整个微服务网络。实际上就是个 高级 proxy cluster + 定制DNS，所有微服务只是将请求换个格式，导入进这个 proxy cluster 中，然后根据其自身或微服务接入时的配置，进行请求采样、处理、传递。

目前期待一下 linkerd2， 根据 issue Linkerd2 without K8s, 还是有希望将其运用到 rancher 1.6 的。

不可对新概念抱有不切实际的幻想！剥开一看，都是当下时代的知识再混合、微创新。

timzaak commented 2 years ago

微服务 k8s 成为王者，它最厉害的敌方应该是开源生态 + Specification 的制定，Rancher1.6、 Docker Swarm 等都是在自己去集成其它组件。而 K8S 是很容易让其它组件集成进来。 现在微服务发展到了 Dapr / Mecha 的阶段，比 Service Mesh 更深一层。把语言+环境当成 Runtime， 然后通过 Sidecar 或 SDK 的方式来屏蔽底层、网络透明化。

SDK 的方式是要带着历史包袱前进，追求平滑过渡，不过估计这个方案会很多人反对，很容易封闭，不容易让第三方加入进来，而 Sidecar 是可以从内核开始重构服务通信方式，着重性能。

Go 成了微服务时代的一等公民，GraalVM、WASM 都要靠边站。至此，所有 GC 语言在服务器端都失去了逆天改命的可能 我先前想 Deno 会怎样，Rust/Typescript/WASM 这三者组合感觉秒杀后台场景，可是晚了，若是 Deno 是 Node.js 时期的产物，还有些可能。