Swoft微服务架构简图

简介

如上图所示，一个主流的微服务架构会由流量代理层、网关、注册中心、服务层（业务复杂时，为了职责清晰通常会拆为基础服务层和聚合服务两层）、配置中心、数据层等几个主要部分构成。

代理层

代理层一般位于流量的入口，可以基于LVS负载均衡、f5负载均衡器、GLB Director、Nginx/OpenResty等中间件来实现。具体细节可以看官方文档，此处不再赘述。

网关

通常，我们的系统中的部分聚合服务接口是需要暴露给外界使用的，这就不可避免的会遇到一些通用性的诉求比如：某些接口需要登录后才能调用（认证/鉴权），某些借口又需要限制调用频次（限流），还有一些情况下新老版本的多个接口要同时使用（A/B Test）…这时候怎么办呢？聪明的你肯定想到了，如果在单体应用的情况下，你可以借助Facade模式作为整个系统的门面，对全部请求进行统一的调度或者过滤，这不但可以使得外部调用方心智负担降低，还可以在一定程度上增强系统的安全性。有很多优秀的通用开源网关实现，如：Kong、Orang，以及目前比较新的Ingress Gateway等等。

注册中心

注册中心时整个分布式服务治理的核心所在，它主要用于实现各个服务实例的自动化注册与发现。其实，刚开始进行服务化，服务并不多的时候，几个服务间完全可以在配置中写死对应服务的配置直接调用，但是当服务逐渐增多时这中手工维护的方式就会导致极其难以维护而且更新不及时，这时候我们就需要引入注册中心了。目前主流的开源注册中心的实现方案也有很多，如：Consul、ETCD、Eureka、甚至Zookeeper等等，不同的注册中心在CAP取舍和业务表现上也有所差异有兴趣的同学可以参考这个对比文档。

配置中心

当我们还是一个单体应用时，我们可以把常用的配置项保存在本地配置文件中。但是当我们的服务实力运行在成百上千的节点中的时候，人工维护这些配置的正确的复杂度则会变得很高。这时候我们需要引入配置中心来统一管理所有服务的配置。开源的配置中心实现有很多，如K8S的ConfigMap，携程开源的Apollo、Spring Cloud Config等等。

数据层