什么是微服务？

六特征

• 一组小的服务

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

• 轻量级通信: 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容器部署技术&持续交付

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