写在前面
本篇是关于系统架构 快速构建和自动化构建的思考, 日期是表明截止这个时间点的思考, 末尾会捎带提一下这块的尝试, 本篇更多还是总结过去与当下
微服务?
小而美不仅是微服务的状态, 也是创业开始的状态，可以简单理解2者天然就是一回事, 随后的发展就开始大相径庭
- 业务 -> 复杂
- 微服务架构 -> 简单
业务变复杂很好理解, 为啥微服务会变简单? 这里通过3点来说明
- 微服务对应应用而言很简单，非业务的功能, 都在微服务的各个组件中实现了
- 微服务的发展, 就是不断让组件更易用更好运维的过程, 过程中伴随着 云原生 不断迭代
- 微服务的现状, 在云厂商几乎都是开箱即用的状态
回顾下微服务的组件
罗列了一些, 看到微服务相关的技术, 只需要知道处于微服务生态位的哪个地方, 以及最佳实践(通常是技术栈的组合)有哪些
- rpc IDL: grpc thift.kitex dubbo jsonrpc.jet brpc srpc
- ServiceRegistryDiscovery.服务注册发现
- provider.server: rateLimit.限流.令牌桶
- transporter > codec > monitor/cache/auth > serviceImpl
- invoker.client: retry.重试 CircuitBreaker.熔断=fallback.降级.本地缓存=服务雪崩
- transporter > codec > monitor/LB/router > proxy
- ServiceMesh.istio flow.traffic.流量
- gateway
- config.配置中心: 敏感信息 watch merge env hotload.热加载 switch.开关
- MQ.消息队列: bus.消息总线 stream.消息驱动 EDA.事件驱动 rocketmq ampq=rabbitmq nats nsq kafka activeMQ RocketMQ
- job: AsyncTask cron consumer
- 事务: DTM seata
- other: session id.NanoID/UUID/雪花算法Snowflake
回顾下微服务的发展
- 历史: MVC>RPC>SOA>MS Monolithic.单体巨石应用 LightwaySOA 分封制 中台 技术上不是问题，意识比工具重要
- 理论: 康威定律 Distributed.分布式
- 设计: 小即是美 单一职责 尽可能早创建原型 可移植性比效率更重要
- 原则: 单一职责 自治 轻量通信 粒度 有效拆分->敏捷开发部署
- 冰山模型 framework: 开发框架+容器技术+基建
- spring: alibaba netfix
- php: hyperf
- go: kitex zeromicro.gozero cloudwego
微服务治理：体系、架构与实践 2020.5
微服务设计模式 2019
可以根据自己的实际情况进行
剪枝/划重点, 上面列举了笔者接触过的内容
微服务+云原生的发展
这里引用一下 周志明-凤凰项目(原文地址不贴了, 这2个关键词就能找到) 中的内容
- 微服务组件相关
| 功能 | Kubernetes | Spring Cloud | other |
|---|---|---|---|
| 弹性伸缩 | Autoscaling | N/A | ... |
| 服务发现 | KubeDNS / CoreDNS | Spring Cloud Eureka | consul etcd zookeeper nacos dubbo |
| 配置中心 | ConfigMap / Secret | Spring Cloud Config | apollo etcd consul nacos acm |
| 服务网关 | Ingress Controller | Spring Cloud Zuul | ... |
| 负载均衡 | Load Balancer | Spring Cloud Ribbon | http.feign/guzzle |
| 服务安全 | RBAC API | Spring Cloud Security | ... |
| 跟踪监控 | Metrics API / Dashboard | Spring Cloud Turbine | sleuth/zipkin/jaeger/skywalking |
| 降级熔断 | N/A | Spring Cloud Hystrix | sentinel |
- 微服务中演进的架构
- 单体
- SOA
- 微服务 over 各个组件(对应上面表格的 SpringCloud + other)
- 微服务 over K8s (对应上表的 kubernetes)
- 微服务 over k8s+ServiceMesh(比如istio)
- 微服务 over Serverless
serverless=终局?
上面微服务的演进(或者说系统架构的演进)到 serverless 划上句号了, 不同人有不同看法, 我倒觉得没必要去争辩这个, 从业务应用的角度来看, 开发阶段不在需要关心微服务中各个组件的概念, 回归了应用本身, 或者说业务应用已经可以不用去理解微服务, CICD后它就已经在那里
现在的开发流程
- 本地 run/debug/test 跑通 -> docker build 跑通 -> k8s deploy
写在最后
顺带一提应用/服务上线后的一些基础设施:
- log: json输出到stdout -> sidecar自动搜集 -> 日志服务自动解析 json
- OpenTelemetry(java/go/py能无侵入自动打点) -> apm -> 监控告警
- 配置管理/ENV管理 -> configmap / SecretConfigmap
- 网络
- 服务间调用 -> k8s Service
- 出公网.NAT网关
- 入公网.LB
目前正在 Serverless应用引擎（新版） 上进行实践: 前方有路, 实践者正在前行
