微服务的技术架构体系涉及到比较多的内容，除了业务代码的开发以外，还需要很多的支撑服务。每个公司都有自己的微服务架构体系，虽然在细节上有很多不同，但是整体的思路是类似的，下图展示了一个比较成熟的微服务架构体系。
对一些成熟的互联网公司来说，其内部都有一个成型的互联网体系，当然不是所有的公司都这么的完善了。对BAT级别的来说，他们内部的体系则比图中还要的细致。
最上面的一层叫做接入层，主要是负载均衡器把外部的流量接入到平台内部中来
最下面的一层叫做基础设施层，一般由运维团队来维护的
最上面的一层和最下面的一层与运维团队比较紧密。
而其中间的部分与微服务体系比较密切。
网关层：是微服务体系中比较核心的部分，有无线网关，第三方应用网关，开发平台网关
业务服务层：一个是聚合层，一个是基础层
支撑服务层：包含，服务注册发现，配置中心，容错限流，监控报警
平台服务：现代的技术团队已经开始引入新的发布体系，如Kubernets
总共有6层体系，这6层体系一般是微服务体系的标准化模板，下面我们将深入相关的技术，不建议初创公司，上去就投入到微服务体系中去。
下面我们对其中关键的几个体系进行讲解：
微服务网关层
为甚要引入网关呢？在我们居住的小区中是不是只有几个门，而在大门旁一般都有门卫，像API网关也相当于门卫，我们的系统中有很多的微服务，但是又不想让这些微服务暴露给客户，这个时候网关就可以屏蔽掉内部的细节。客户只需要访问网关就可以了。
最好将网关部署为无状态的，这个时候可以部署多台，更容易的实现集群。网关在其中承担的功能：
反向路由：当外面的请求进来的时候，如何找到具体的服务，这就是反向路由
认证安全：有些是正常访问，有些是恶意访问，需要网关进行辨别
限流熔断：比如说小区的大门突然进来了很多人，这个时候最好对大门进行限流，防止内部过度拥挤。
日志监控：外面的请求去访问内部的服务，那么就要对东西做一些审计，分析调用的性能情况，对整个服务流量进行监控
目前社区的关于 API Gataway 的项目：
Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。
Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。
Orange：和Kong类似也是基于OpenResty的一个API网关程序，是由国人开发的，学姐也是贡献者之一。
Zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。具有很灵活的路由过滤功能
apiaxle: Nodejs 实现的一个 API 网关。
在Java体系中，一般会选用Zuul作为网关。
参考：
微服务配置中心
配置中心在微服务体系中有什么样的作用呢？想想如果没有配置中心，很多的公司刚开始都没有配置中心的概念，开发人员一般把配置放在配置文件中，并且每个人的做法都不一样，另外一个就是如果需要修改配置的时候都要重新发布服务，还有如果没有集中式的配置的话，我们也不知道到底是谁修改了配置。
那些东西东西可以作为配置呢？
连接字符串，数据库连接地址，缓存连接地址，MQ连接地址
动态调整参数，如超时，限流的阈值
业务的开关，某个功能只对某个地区生效
如果通过发布去配置这些东西，将会耗时很长，而通过配置中心，则是十分的灵活。所以微服务架构中一定要有一个配置中心。
应用连接到配置中心，可以实时的更新配置，可能是实时的拉取，也有可能是配置中心服务器推送，两种做法各有利弊。
拉配置的话可能无法实时更新
推的话可以实时更新，但需要配置中心性能较高
目前已经开源的常用配置中心服务器：
Apollo 携程开源
Spring Cloud ConfiServer Spring的全家桶组件
Disconf 百度
参考：
微服务通讯体系
微服务中比较典型的两种通讯方式，RPC与Http两种方式各有优劣，这里我们对两种通讯方式做一个比对
那么如何根据自己的业务场景进行选择呢？
RPC性能优于REST 但是RPC不方便调试
REST可以直接上手，基于常见的HTTP协议
一般开发语言都会支持REST，而堆RPC需要额外的支持，REST对开发人员比较友好
参考：
微服务的服务治理
当一个国家人多了，需要政府来进行管理，东西多了，也需要进行管理分类，在微服务体系中，如果服务多了，需要管理和治理。那么一个好的微服务体系，需要关注那些点呢？
1 首先需要知道服务的集成
2 服务要提供高可用，负载均衡的功能
3 服务需要能路由
4 对微服务进行监控，调用链监控，系统指标监控，后期用于定位问题
5 限流熔断，也是保证微服务高可用的一种方式
6 好的微服务框架如果能同时支持两种调用方式RPC与REST就很不错
7 最后需要文档来记录服务中的各种重要内容，方便新人快速了解系统。
以上是设计的时候要考虑到的点。主要是保证服务的可用性，健壮性，扩展性，以及易用性上。一般服务治理的框架都会提供这些功能：服务降级、服务流控、服务动态扩展、超时控制、优先级调度、负载均衡策略调整
市场上有关服务治理的框架：
部分小公司会选择Dubbo，或者eureka作为自己的服务治理框架，稍具规模的公司可能会选择自研相关框架，只需要具备上述的功能就行了。
最后
这里有关微服务的技术架构体系，我们主要说了一些服务相关的东西，服务可以类比成人，而人是需要有衣食住行的，配置中心，通讯，治理，就是服务的必备存活条件。微服务体系可以衍变为多种多样的形式，主要对微服务的体系有个认知，这样在公司快速发展的过程中仍然能从容应对。
注：
本文独家发布自金蝶云社区
