多次尝试学习，终于搞懂了微服务架构

使用了微服务架构体系，团队组织方式需要转变成跨职能团队，即每个团队都有产品专家，策划专家，开发专家，运维专家，他们使用 API 方式发布他们的功能，而平台使用他们的功能发布产品。

微服务技术架构体系

下面我分享一下大部分公司都使用的微服务技术架构体系：

服务发现

主流的服务发现，分为三种：

第一种，开发人员开发了程序以后，会找运维配一个域名，服务的话通过 DNS 就能找到我们对应的服务。

缺点是，由于服务没有负载均衡功能，对负载均衡服务，可能会有相当大的性能问题。

第二种，是目前普遍的做法。可以参考 Zuul 网关，每一个服务都通过服务端内置的功能注册到注册中心，服务消费者不断轮询注册中心发现对应的服务，使用内置负载均衡调用服务。

缺点是，对多语言环境不是很好，你需要单独给消费者的客户端开发服务发现和负载均衡功能。当然了，这个方法通常都是用在 Spring Cloud 上的。

第三种，是将客户端和负载均衡放在同一个主机，而不是同一个进程内。

这种方法相对第一种第二种方法来说，改善了他们的缺点，但是会极大增加运维成本。

网关

微服务的网关是什么?我们可以联系生活实际想一下。每一个大的公司，都会有一偏属于自己的建筑区，而这建筑区内，都有不少的门卫。如果有外来人员进入公司，会先和门卫打好招呼，才能进去。

将生活实际联系到微服务上，就不难理解网关的意思了：

网关的作用如下：

反向路由：很多时候，公司不想让外部人员看到我们公司的内部，就需要网关来进行反向路由。即将外部请求转换成内部具体服务调用。

安全认证：网络中会有很多恶意访问，譬如爬虫，譬如黑客攻击，网关维护安全功能。

限流熔断：当请求很多服务不堪重负，会让我们的服务自动关闭，导致不能用服务。限流熔断可以有效的避免这类问题。

日志监控：所有的外面的请求都会经过网关，这样我们就可以使用网关来记录日志信息。

灰度发布，蓝绿部署。是指能够平滑过渡的一种发布方式。在其上可以进行 A/B testing。

即让一部分用户继续用产品特性 A，一部分用户开始用产品特性 B，如果用户对 B 没有什么反对意见，那么逐步扩大范围，把所有用户都迁移到 B 上面来。

开源网关 Zuul 架构：

Zuul 网关核心其实是一个 Servlet，所有请求都会经过 Zuul Servlet 传到 ZuulFilter Runner，然后分发到三种过滤器。

先说说架构图左半部分，分别是使用 Groovy 实现的前置路由过滤器，路由过滤器，后置路由过滤器。

一般请求都会先经过前置路由过滤器处理，一般的自定义 Java 封装逻辑也会在这里实现。

路由过滤器，实现的是找到对应的微服务进行调用。调用完了，响应回来，会经过后置路由过滤器，通过后置路由过滤器我们可以封装日志审计的处理。

可以说 Zuul 网关最大的特色就是它的三层过滤器。架构图右半部分，是 Zuul 网关设计的自定义过滤器加载机制。

网关内部会有生产者消费者模型，自动的将过滤器脚本发布到 Zuul 网关读取加载运行。

配置中心

以前，开发人员把配置文件放在开发文件里面，这样会有很多隐患。譬如，配置规范不同，无法追溯配置人员。

一旦需要大规模改动配置，改动时间会很长，无法追溯配置人员，从而影响整个产品，后果是我们承担不起的。

因此就有配置中心这个喽!现在的开源中心有百度配置中心 Disconf，Spring Cloud Config，Apollo。

今天重点说说现在应用质量不错的配置中心，携程开源的阿波罗(Apollo)：

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!