深刻理解分析微服务(上)

深刻理解分析微服务(上)

前言;

今年有人提出了2019年微服务将疯狂至死，可见微服务的争论从未中止过。在这我将本身对微服务的理解整理了一下，但愿对你们有所帮助。因为篇幅太长，小编把他分为了上下篇，记得关注我哦

什么是微服务

1）一组小的服务（大小没有特别的标准，只要同一团队的工程师理解服务的标识一致便可）

2）独立的进程（java的tomcat，nodejs等）

3）轻量级的通讯（不是soap，是http协议）

4）基于业务能力（相似用户服务，商品服务等等）

5）独立部署（迭代速度快）

6）无集中式管理（无须统一技术栈，能够根据不一样的服务或者团队进行灵活选择）

ps：微服务的先行者Netflix公司，开源了一些好的微服务框架，后续会有介绍。

怎么权衡微服务的利于弊

利：

强模块边界 。（模块化的演化过程：类-->组件/类库（sdk）-->服务(service)，方式愈来愈灵活）

可独立部署。

技术多样性。

弊：

分布式复杂性。

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

运维复杂性。

测试复杂性。

企业在何时考虑引入微服务

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

有些架构师是具备微服务架构能力，因此设计系统时就直接设计成了微服务，而不是经过单服务慢慢演化发展成微服务。在这里我并不推荐这种作法，由于一开始对业务领域并非很了解，而且业务模式尚未获得验证，这时候上微服务风险比较高，颇有可能失败。因此建议你们在单服务的应用成熟时，而且对业务领域比较熟悉的时候，若是发现单服务没法适应业务发展时，再考虑微服务的设计和架构。

微服务的组织架构

如上图左边，传统的企业中，团队是按职能划分的。开发一个项目时，会从不一样的职能团队找人进行开发，开发完成后，再各自回到本身的职能团队，这种模式实践证实，效率仍是比较低的。

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

怎么理解中台战略和微服务

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

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

服务分层

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

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

1：基础服务： 好比一个电商网站，商品服务和订单服务就属于基础服务（核心领域服务）。缓存服务，监控服务，消息队列等也属于基础服务（公共服务）

2：聚合服务 ：例如网关服务就算一种聚合服务（适配服务）。

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

微服务的技术架构体系

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

1：接入层 负载均衡做用，运维团队负责

2：网关层 反向路由，安全验证，限流等

3：业务服务层 基础服务和领域服务

4：支撑服务层

5：平台服务

6：基础设施层 运维团队负责。（或者阿里云）

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

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

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

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

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

微服务网关

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

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

Netflix Zuul网关介绍

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

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

整个网关调用的流程

上图从左变http Request开始通过三类过滤器，最终到最右边的Http Response，这就是Zull网关的整个调用流程。

微服务的路由发现体系

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

微服务配置中心

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

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

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

RPC遇到了REST

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

上半部分先分享到这里，记得关注我哦，天天都会分享java有关的文章