了解微服务架构

P1 - 什么是微服务架构？

Loosely Coupled （松耦合）

Service Oriented architecture（基于SOA架构）

with bounded Context（有界上下文，局部状态；每个团队可以管理自己的数据源，没有集中式的数据管理）

Martin Fowler（https://martinfowler.com/）是如此定义微服务的

“In short, the microservice architectural style is an approach to developing a single application as a suite of small services, each running inits own process and communicating with lightweight mechanisms, often an HTTPresource API”

微服务框架

一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致即可）
独立的进程（java的tomcat，nodejs等）
轻量级通信（不是soap，是http协议）
基于业务能力（类似用户服务，商品服务等）
独立部署（迭代速度快）
无集中式管理（无须统一技术栈，可以根据不同的服务或者团队进行灵活选择）

问题：

1.微服务的一个特点是独立部署，那独立部署给我们的微服务，给业务带来什么样的好处？

2.微服务是基于有界上下文，每个团队可以有自己独立的数据源，那么在分布式系统当中又带来什么样的挑战？

ps：微服务的先行者Netflix公司，开源了一些好的微服务框架

P2 - 如何权衡微服务的利弊？

利：

强模块化边界。（模块化的演化过程：类–>组件/类库（sdk）–>服务(service)，方式越来越灵活）
可独立部署。
技术多样性。

弊：

分布式复杂性。
最终一致性。（各个服务的团队，数据也是分散式治理，会出现数据不一致的问题）
运维复杂性。
测试复杂性。

与单块应用相比不同。

微服务有利也有弊。

问题：

1.微服务对运维来说挑战是非常巨大的，运维团队在面对微服务的复杂性的时候应运用什么样的手段？

P3 - 康威法则和微服务给予我们怎样的启示？

康威法则：

设计系统的企业受限于生产设计，这些设计是企业沟通结构的副本——Melvin Conway(1967)

这意味着设计系统的企业，它们生产的设计等同于企业内的沟通结构。下图说明了此概念：

康威法则是微服务的理论基础。

单块应用架构没有组织的概念，效率很低（团队间的沟通效率低）。

问题：

为什么作为架构师，不仅要了解技术架构，也要了解组织的组织架构？

P4 - 企业应该在什么时候开始考虑引入微服务？

从生产力和系统的复杂性这两个方面来看。公司一开始的时候，业务复杂性不高，这时候是验证商业模式的时候，业务简单，用单体服务反而生产力很高。随着公司的发展，业务复杂性慢慢提高，这时候就可以采用微服务来提升生产力了。至于这个转化的点，需要团队的架构师来进行各方面衡量，就个人经验而言，团队发展到百人以上，采用微服务就很有必要了。

有些架构师是具有微服务架构能力，所以设计系统时就直接设计成了微服务，而不是通过单服务慢慢演化发展成微服务。在这里我并不推荐这种做法，因为一开始对业务领域并不是很了解，并且业务模式还没有得到验证，这时候上微服务风险比较高，很有可能失败。所以建议大家在单服务的应用成熟时，并且对业务领域比较熟悉的时候，如果发现单服务无法适应业务发展时，再考虑微服务的设计和架构。

P5 - 微服务的组织架构

传统的企业中，团队是按职能划分的。开发一个项目时，会从不同的职能团队找人进行开发，开发完成后，再各自回到自己的职能团队，这种模式实践证明，效率还是比较低下的。

而如果像右边的，围绕每个业务线或产品，按服务划分团队。团队成员从架构到运维，形成一个完整的闭环。一直围绕在产品周围，进行不断的迭代。不会像传统的团队一样离开。这样开发效率会比较高。至于这种团队的规模，按照亚马逊的两个披萨原则，大概10人左右比较好。

P6 - 如何理解中台战略和微服务

中台战略的由来：马云2015年去欧洲的一家公司supersell参观，发现这个公司的创新能力非常强，团队的规模很小，但是开发效率很高。他们就是采用中台战略。马云感触很深，回国后就在集团内部推出了中台战略。

简单的理解就是把传统的前后台体系中的后台进行了细分。阿里巴巴提出了大中台小前台的战略。就是强化业务和技术中台，把前端的应用变得更小更灵活。当中台越强大，能力就越强，越能更好的快速响应前台的业务需求。打个比喻，就是土壤越肥沃，越适合生长不同的生物，打造好的生态系统。

P6 - 服务分层

每个公司的服务分层都不相同，有的公司服务没有分层，有的怎分层很多。目前业界没有统一的标准。

下面推荐一个比较容易理解的两层结构。

基础服务：比如一个电商网站，商品服务和订单服务就属于基础服务（核心领域服务）。缓存服务，监控服务，消息队列等也属于基础服务（公共服务）
聚合服务：例如网关服务就算一种聚合服务（适配服务）。

这是一种逻辑划分，不是物理划分，实际设计的东西很多很复杂。

P7 - 微服务的技术架构体系

如下是一个成型的互联网微服务的架构体系：

接入层负载均衡作用，运维团队负责
网关层反向路由，安全验证，限流等
业务服务层基础服务和领域服务
支撑服务层
平台服务
基础设施层运维团队负责

P8 - 微服务的服务发现三种方式

第一种：如下图所示，传统的服务发现（大部分公司的做法）。服务上线后，通知运维，申请域名，配置路由。调用方通过dns域名解析，经过负载均衡路由，进行服务访问。缺点： LB的单点风险，服务穿透LB，性能也不是太好;

第二种：也叫客户端发现方式。如下图所示。通过服务注册的方式，服务提供者先注册服务。消费者通过注册中心获取相应服务。

并且把LB的功能移动到了消费者的进程内，消费者根据自身路由去获取相应服务。优点是，没有了LB单点问题，也没有了LB的中间一跳，性能也比较好。但是这种方式有一个非常明显的缺点就是具有非常强的耦合性。针对不同的语言，每个服务的客户端都得实现一套服务发现的功能。

第三种：也叫服务端发现方式，如下图所示。和第二种很相似。但是LB功能独立进程单独部署，所以解决了客户端多语言开发的问题。唯一的缺点就是运维成比较高，每个节点都得部署一个LB的代理，例如nginx。

P9 - 微服务网关

网关就好比一个公司的门卫。屏蔽内部细节，统一对外服务接口。

下图是一个网关所处位置的示例图。

P10 - Netflix Zuul网关介绍

核心就是一个servlet，通过filter机制实现的。主要分为三类过滤器：前置过滤器，过滤器和后置过滤器。

主要特色是，这些过滤器可以动态插拔，就是如果需要增加减少过滤器，可以不用重启，直接生效。原理就是：通过一个db维护过滤器（上图绿色部分），如果增加过滤器，就将新过滤器编译完成后push到db中，有线程会定期扫描db，发现新的过滤器后，会上传到网关的相应文件目录下，并通知过滤器loader进行加载相应的过滤器。

请求过来了, 首先会进入一系列的前置过滤器pre filter.
前置过滤器处理完了, 进入routing filter路由过滤器, routing filter路由过滤器是真正的向后台服务发起请求, 接收响应的过滤器
经过routing filter路由过滤器, 最后会传递过post filter 后置过滤器,进行一些后续的处理, 这时候已经拿到响应了, 然后在返回给客户端.
在这三个过滤器过滤的过程中,任何一个环节发生错误, 都会进入error filter. 有error filter进行统一的错误处理. error filter错误过滤器会发送给post filter, 也是以响应的方式发回给客户端.

这是一个请求, 在网关处理的生命周期. 上图从左变http Request开始经过三类过滤器，最终到最右边的Http Response，这就是Zull网关的整个调用流程。

P11 - 微服务的路由发现体系

整个微服务的路由发现体系，一般由服务注册中心和网关两部分组成。以NetFlix为例子，Eureka和Zull这两个组件支撑了netFlix整个的路由发现体系。如下图所示，首先外部请求发送到网关，网关去服务注册中心获取相应的服务，进行调用。其次内部服务间的调用，也通过服务注册中心进行的。

P12 - 微服务配置中心

目前大部分公司都是把配置写到配置文件中，遇到修改配置的情况，成本很高。并且没有修改配置的记录，出问题很难追溯。配置中心就接解决了以上的问题。

可配置内容：数据库连接，业务参数等等；

配置中心就是一个web服务，配置人员通过后台页面修改配置，各个服务就会得到新的配置参数。实现方式主要有两种，一种是push，另一种是pull。两张方式各有优缺点。push实时性较好，但是遇到网络抖动，会丢失消息。pull不会丢失消息但是实时性差一些。大家可以同时两种方式使用，实现一个比较好的效果。如下图所示，这是一个国内知名互联网公司的配置中心架构图。

开源地址：http://github.com/ctripcorp/appollo

P13 - 当RPC遇到了REST

内部一些核心服务，性能要求比较高的可以采用RPC，对外服务的一般可以采用rest。

P14 - 服务框架和治理

微服务很多的时候，就需要有治理了。一个好的微服务框架一般分为以下14个部分。如下图所示。这就是开篇所说的，微服务涉及的东西很多，有些初创公司和业务不成熟的产品是不太适合的，成本比较高。

目前国内比较好的微服务框架就是阿里巴巴的DUBBO了,国外的就是spring cloud,大家可以去研究一下.

P15 - 监控体系

监控是微服务治理的重要环节。一般分为以下四层。如下图所示。

监控的内容分为五个部分：日志监控，Metrics监控（服务调用情况），调用链监控，告警系统和健康检查。

日志监控，国内常用的就是ELK+KAFKA来实现。健康检查和Metrics，像spring boot会自带。Nagios也是一个很好的开源监控框架。

P16 - Trace调用链监控

调用链监控是用来追踪微服务之前依赖的路径和问题定位。例如阿里的鹰眼系统。主要原理就是子节点会记录父节点的id信息。

下图是目前比较流行的调用链监控框架。

P17 - 微服务的限流熔断

假设服务A依赖服务B和服务C，而B服务和C服务有可能继续依赖其他的服务，继续下去会使得调用链路过长。如果在A的链路上某个或几个被调用的子服务不可用或延迟较高，则会导致调用A服务的请求被堵住，堵住的请求会消耗占用掉系统的线程、io等资源，当该类请求越来越多，占用的计算机资源越来越多的时候，会导致系统瓶颈出现，造成其他的请求同样不可用，最终导致业务系统崩溃。

一般情况对于服务依赖的保护主要有两种方式：熔断和限流。目前最流行的就是Hystrix的熔断框架。

限流方式可以采用zuul的API限流方法。

P18 - Docker 容器部署技术&持续交付流水线

随着微服务的流行，容器技术也相应的被大家重视起来。容器技术主要解决了以下两个问题：

1：环境一致性问题。例如java的jar/war包部署会依赖于环境的问题（操着系统的版本，jdk版本问题）。

2：镜像部署问题。例如java，rubby，nodejs等等的发布系统是不一样的，每个环境都得很麻烦的部署一遍，采用docker镜像，就屏蔽了这类问题。

下图是Docker容器部署的一个完整过程。

更重要的是，拥有如此多服务的集群环境迁移、复制也非常轻松，只需选择好各服务对应的Docker服务镜像、配置好相互之间访问地址就能很快搭建出一份完全一样的新集群。

P19 - 容器调度和发布体系

目前基于容器的调度平台有Kubernetes，mesos，omega。下图是mesos的一个简单架构示意图。

下图是一个完整的容器发布体系：

随着持续交付概念推广以及Docker容器普及，微服务将这两种理念和技术结合起来，形成新的微服务+API + 平台的开发模式，提出了容器化微服务的持续交付概念。

微服务促进了DevOps方式的重组，将一个大臃肿的整体产品开发队伍切分为根据不同微服务的划分的产品队伍，以及一个大的整体的平台队伍负责运营管理，两者之间通过API交互，做到了松耦合隔绝。

首先需要考虑构建DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源；

其次保持服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化；

同时要保持团队和架构对齐。微服务貌似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。

最后，打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现我们的初衷。

微服务的实施是有一定的先决条件：基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入如我们般被动的局面。推荐采用基础设施及代码的实践，通过代码来描述计算和网络基础设施的方法，使得图案度i可以快速安全的搭建和处理由新的配置代替的服务器，服务器之间可以拥有更高的一致性，降低了在“我的环境工作，而你的环境不工作”的可能，也是为后续的发布策略和运维提供更好的支撑。

1626867340070