微服务设计

不要把一堆鸡蛋放在同一个篮子里面。在投资的时候，我们一般不会把全部身家都放在一只股票或基金上面，一般都会采取组合的形式，进行投资理财，分摊风险，降低亏损率。软件服务也是一样，如果是单点服务，如果出现故障，那么整个服务也将不可用了，对整个产品造成恶劣的影响，导致用户大面积流失。

一、去中心化

在微服务中，一般我们需要三个去中心化：

1. 技术去中心化
2. 数据去中心化
3. 治理去中心化

技术去中心化

在开发微服务中，每个服务面向的业务场景皆不相同，有些是数据密集型业务服务，需要大内存大存储，如：内容系统。有些是计算密集型，需要良好的

CPU 或 GPU 进行大量计算提供服务，如：AI，视频处理等。我们需要为不同的服务选择不同的技术解决方案。在选择技术栈时，要避免过度多样化，需要结合团队实际的情况来取舍，要是没个服务都是用不同的语言来实现，维护成本将会很高。

数据去中心化 — 服务之间通过 RPC 通讯

微服务中，每个服务将独享自身的数据存储设施(数据库and缓存等)，不像传统的应用共享一个

DB 和 Cache。这样有利于服务的独立性，隔离相关干扰。

治理去中心化

当出现流量热点时，大流量访问某一个服务，流量经过

Nginx 进行转发，单个 Nginx 服务无法承载大量流，那么，就需要部署多套 Nginx，防止单个 Nginx 服务被大流量打死，从而导致服务不可用。一般的，遇到服务瓶颈时，要考虑纵向扩展与横向扩展的成本，进行对比，选择目下最佳方案。

二、 基础设施自动化

一般来说，无自动化不微服务，一旦实行微服务架构，就意味着不再像传统的应用，始终只有很少的服务，部署起来很方便。微服务一般都会拆成十几二十个(主要看应用规模)，可独立运行的服务，这意味着，开发，调试，测试，监控和部署复杂度会相应的增大，必须要有合适的自动化基础设施来支持微服务的架构模式。

一般基础设施(包括不限于)

1. CI/CD — Gitlab + Gitlab Hooks + k8s
2. Testing — 单元测试， API 自动化测试(Yapi)
3. 在线运行时 — k8s， 以及一系列的，日志收集，日志监控，性能监控等等

三、服务可用性与兼容性

可用性

微服务架构采用粗粒度的进程间通信，引入了额外的复杂性和需要处理的新问题，如：网络延迟，消息格式，负载均衡和容错。提高可用性需要关注如下几点：

1. 隔离
2. 超时控制
3. 负载保护
4. 限流
5. 降级
6. 重试
7. 负载均衡

兼容性

一单采用了微服务架构模式，那么在微服务变更时，我们需要特别小心，服务提供者的变更可能引发服务消费者的兼容性被破坏，需要时刻谨记保持服务契约接口的兼容性，一般的原则是遵循博斯塔尔法则 — 发送时保守,接收时开放，在开发时，面向失败编程，提高代码的鲁棒性。

1. 发送时保守 — 最小化传递必要的信息
2. 接收时开放 — 最大限度容忍冗余数据，保证兼容性

四、组件服务化

传统实现组件的方式是打包成一个库，如：

Java 下的 Jar 包， Windows 下的 .dll，Linux 下的 .so，都属于一个库，集成进现有的应用，就可以使用库提供的相应的功能。库和现有的应用打包成一个可执行的服务，运行在同一个进程中，这意味着库的局部变化，整个应用都需要重新部署。在微服务模式下，通过微服务实现组件，将单个应用拆分为一系列的服务组件，运行在不同的进程中，那么单一服务的局部变化，只需要更新部署对应的服务进程即可。

Golang 实现一个微服务组成

Kit — 一个微服务的基础库(框架)， 如： go-kit, go-micro, kratos,TarsGo

Service — 业务代码 + kit 依赖 + 第三方依赖，组成业务微服务

RPC + Message Queue — 轻量级通讯, 如：gRpc, Rest Api

五、服务划分

按业务组织服务 —— 按业务能力组织服务的意思是服务提供的能力和业务能力对应。譬如：

订单服务 和 数据访问服务，前者反映了真是的订单服务，后者则是一种技术抽象服务，不能反映真是的业务，所有按微服务架构的理念来划分时，是不应该存在 数据访问服务 这样的一个服务的。

事实上，传统应用设计架构的分层结构，正反映了不同角色的沟通结构，所有若按微服务的方式来构建应用，也需要对应调整团队的组织架构，每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面技能。

传统组织结构

传统应用架构的组织架构，按照职能划分，如 UI 组，开发组，DBA 组，运维组等等，

微服务组织结构

微服务架构模式下的组织架构下，每个服务背后的小团队的组织是跨功能的，包含实现业务所需的全面技能。