目录
微服务是一种工程方法，聚焦在将应用拆解为具备良好接口设计的单一功能的模块集上。模块集可以独立部署，由掌管整个生命周期的小团队维护。
微服务最小化了人与人之间的沟通和协作，进而减小应用范围和变更的风险。
抽几个来讲一下：
- 单一功能：一个服务聚焦一个”类型的”功能上
- 良好接口设计：服务间的通信依赖接口，简单清晰的接口是基础
- 独立：服务具备独立运行工作的能力，包括流水线、监控、上线等
- 整个生命周期：团队负责从开发-测试-staging-部署-维护的整个阶段
- 语言无关：服务间通信使用语言无关的API，通常由RESTful的接口、RPC等实现
- 有限上下文：松耦合，服务单元不需要了解其他服务单元如何运作
随着时间演进，大型、复杂的单体应用逐步演化出多层架构（MVC等），但按照业务功能的分层仍然笨拙、复杂、难以控制。
从单体服务迁移成微服务
核心就是面向业务拆分服务
设计时考虑失败
- 熔断机制
- 设计初衷是保证一个服务故障不会影响整个系统
- 当某个服务调用失败比例提高，合理的使用其他方式提供服务
- 隔离
- 单个服务造成的负载问题不影响其他服务
- 设计服务的资源用量
去中心化数据管理
单体应用的事务管理更容易。相较ACID，微服务架构更偏重BASE
- BASE
- BA：Basically Available， 基本可用
- S：Soft state，无状态
- E：Eventual consistency，最终一致性。中间可以失败重试，但最终结果要保持一致。
- 尽可能的避免分布式事务，因为BASE还是会有各种坑
- 理想情况下每个微服务单元管理自己的数据
服务发现
- 微服务架构要求服务可靠和容错
- 云计算和容器化的微服务，服务配置动态化。新服务单元创建后，需要网络中的其他服务快速找到并相互调用
- 使用注册服务中心管理服务状态(例如使用zk，etcd等搞一个配置中心)
- 使用服务内通信设置，更少的依赖外部环境：IP\域名\hostname...
服务通信
- API调用
- RPC
- 消息机制：mq，劣势是实时性，优势是可以延迟处理
k8s+微服务
SaaS的12要素
https://12factor.net/zh_cn/
- 基准代码：一分代码多处部署
- 依赖：显示声明依赖关系
- 配置：在环境中存储配置
- 后端服务：把后端服务当做附加资源
- 构建、发布、运行：严格分离构建和运行
- 进程：一个或多个无状态进程运行应用
- 端口绑定：通过端口绑定提供服务
- 并发：通过进程模型进行扩展
- 易处理：快速启动和优雅终止可最大化健壮性
- 开发与线上环境等价：尽可能的保持开发，预发布，线上环境相同
- 日志：把日志当作事件流
- 管理进程：后台管理任务当作一次性进程运行
Kubernetes的设计适合微服务
- 服务发现Service
- 服务编排与弹性伸缩
- 统一配置中心：对于配置中心，K8S 提供了 configMap，可以在容器启动的时候，将配置注入到环境变量或者 Volume 里面。但是唯一的缺点是，注入到环境变量中的配置不能动态改变了，好在 Volume 里面的可以，只要容器中的进程有 reload 机制，就可以实现配置的动态下发了。
- 统一日志与监控：统一日志和监控往往需要在 Node 上部署 Agent，来对日志和指标进行收集，当然每个 Node 上都有，daemonset 的设计，使得更容易实现
- Container Liveness
- Readness Probe
- Node-Problem-Detector
- 滚动更新
搞
设置账号密码
echo -n "root" > username
echo -n 'root123!' > password
kubectl create secret generic user-password --from-file=username --from-file=password
comment here..