微服务

集中式架构 -> 垂直拆分 -> 分布式服务 -> 服务治理(SOA) -> 微服务

选择微服务的动力

外部因素:

内部因素:

微服务的弊端

微服务需要的条件

概念

微服务的粒度

  1. 微服务粒度的下界是它至少应满足独立——能够独立发布、独立部署、独立运行与独立测试,内聚——强相关的功能与数据在同一个服务中处理,完备——一个服务包含至少一项业务实体与对应的完整操作
  2. 微服务粒度的上界是一个2 Pizza Team能够在一个研发周期内完成的全部需求范围

在这种开发模式中,技术人员也会快速积累业务知识,业务会沉淀到技术人员个人层面。每个人负责某个特性从开发到测试再到运维各方面,也就是DevOps

原则

什么时候不适合微服务

对要构建的系统越不熟悉,对系统的各个组件划分也就越困难

所以还是先构建单体系统,再逐步对其拆分

什么时候转微服务

好处

面向服务的架构(SOA)

SOA是一种设计方法,其中包含多个服务,而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用,而非采用进程内调用的方式进行通信。

微服务架构可以看做是实现SOA的一种特定方法

其他的分解技术

架构师的视角

软件不同于建筑,相对来说,软件的不可预测因素更多,我们应该设计出一个合理的框架,在这个框架可以慢慢演化出正确的系统,也就是生长的架构。

避免对所有事情做出过于详尽的设计,将注意力专注在大方向上

同时,架构设计就是在做取舍,要有原则及实践来指导设计

分区

相对来说,应该多担心区域之间发生的交互,而非区域内的事情

良好的服务应该具有的属性

代码治理

技术债务

短期的利益,长期来看是要付出代价的,应该要维护好这个债务列表

例外管理

一次例外是例外,多次例外就是规则了

系统设计

微服务的架构决定了对架构者的能力要求非常高 而允许平庸开发者的存在

这点与软件工艺理论不谋而合

康威定律

即系统设计本质上反映了企业的组织机构。系统各个模块间的接口也反映了企业各个部门之间的信息流动和合作方式

批注 2020-03-24 092008

批注 2020-03-24 092048

服务所有权

拥有服务的团队可以对服务做出修改,只要不影响服务的消费者

为什么要共享服务

多个团队共同维护一个服务

内部开源

不再采取团队结构,而是让一小部分人称为核心提交者,其他人可以提交PR

孤儿服务

孤儿服务指的是一段时间没有更改的服务

如果团队的组织是按照限界上下文的话,那一个团队可能拥有多个服务,这个孤儿服务在这个团队手上,当发生需求变更时,修改是很容易的。同时,采取了微服务的架构,很多服务都可以进行快速重写

反向的康威定律

主链路规划

开源:将边缘计算资源调配给主链路业务

节流:限流降级熔断

挑战

生命周期

设计

部署

监控

四层架构

批注 2020-06-18 155555

平台层

批注 2020-06-18 155742

服务层

实现业务功能或者技术功能的微服务

通信

服务边界

用来屏蔽内部实现细节,提供一个外部统一访问点

客户端

查询

远程调用接口的代价很大,需要对一些查询接口提供批量查询接口

高可靠微服务

故障类型

后备方案

超时

断路器

为了保护服务

异步通信

可复用的微服务框架