什么是微服务?

六特征

  • 一组小的服务

  • 独立的进程: 例如容器等

  • 轻量级通信: http,json

  • 基于业务能力

  • 独立部署:团队间无依赖,独立进行,迭代速度快

  • 无集中式管理:可以使用独立的技术栈

特点

  • 松散耦合(loosely coupled)
  • 面向服务(soa)
  • 独立数据源(bounded context)
思考:独立部署后有什么好处? 每个团队独立数据源时有什么挑战?

微服务利弊权衡

  • 强模块化边界
  • 可独立部署(低协同开销)
  • 技术多样性

  • 分布式复杂性
  • 最终一致性
  • 运维复杂性
  • 测试复杂性
思考:运维团队如何面对这样的复杂性?

康威法则

设计系统的组织,其产生的设计和架构等价于组织间的沟通结构

单块应用与多团队矛盾,沟通协同成本大,测试复杂,交付能力差

思考:架构师为什么既需要再考虑技术架构时也要去考虑组织架构?

企业应该在什么时候引入微服务?

初期主要是验证商业模式,而微服务存在基础设施的投资,需要一定的基础设施。

一般认为团队接近百人时考虑

我在设计初期时如何考虑呢?

单块优先(未验证商业模式,模式不成熟稳定,因此风险高),逐步引入,逐步分解
思考:架构是设计出来的还是演化出来的?

什么样的组织架构更适合微服务?

传统组织架构及其缺点:

产品管理团队,用户体验团队,研发团队,测试团队,...DBA团队,运维团队

缺点:沟通协同成本大,反馈周期长,研发效率低下,业务支持慢

基于微服务的跨职能的团队

微服务的跨职能的团队[一般12人左右]*n==>API|团队平台

端到端:who build it,who run it
思考:如何理解微服务本质上是一种组织架构的重组?

如何理解阿里巴巴提出的微服务的中台战略?

大中台小前台

知乎:中台到底是什么?
思考:对于架构师大中台小前台战屡如何在自己的公司实现?

服务分层

逻辑性的分层

思考:如何将目前公司的服务映射到基础服务和聚合服务上

微服务总体技术架构体系

思考: 为什么初创团队直接切入微服务?

最经典的三种服务发现机制

服务发现:消费者寻找生产者

1. 传统基于LB模式【简单,需要运维介入,集中式LB挂掉可能导致整个服务无法访问,有一些性能损失】

2. 进程内LB模式【无集中式LB即不存在单点问题,性能好,必须为每个client开发均衡器,多语言支持成本高】

3. 主机读LB模式【方案12的结合,需要每一台主机上运行一个LB 运维成本高】

思考:最新提出的service mesh使用的是哪一种服务发现机制?

微服务网关原理

为什么要引入网关?屏蔽内部细节

无状态==>可批量部署===>高可用

思考:有一些架构师在网管层接入业务,这样做的的好处和弊端

开源网关zuul

zuul servlet ==>zuul Filter Runner ==>{pre routing filter | routing filter| post routing filter}

思考:如果增加一个反爬虫的功能应该在哪个阶段上?

服务发现[netflix为例]

思考:参考如上体系,如何建立一个服务发现体系

配置中心

传统设计的缺点:

格式不标准,不统一,修改周期长,无配置管理审计功能=>难以追责

哪些东西可放在配置中心?

数据库,缓存,消息队列连接字符串,动态连接的参数,限流阈值,业务开关

当前一些常见的配置中心:

spring cloud config , apollo (携程),Minerva(斗鱼)

通讯方式 RPC vs REST

微服务框架需要考虑哪些治理

思考:了解dubbo框架

监控系统分层和架构

调用链监控

容错限流

Docker容器部署技术&持续交付

容器集群调度&基于容器的发布体系