目录
一、 微服务技术生态
前面一篇文章，我们对微服务的基本概念，微服务带来的问题与挑战进行了描述。这篇文章我们来看看在微服务的技术生态中，用了哪些术与方案来解决这些问题。
我画了一张微服务的计算生态圈地图，通过这张地图可以对微服务整体解决方案有个全局观，就像带孩子游玩动物园，如果手里拿着一张向导地图，那我们就不会错过重要的景点。当然，光凭一张图我们不可能讲明白设计原理、代码实现等这些细枝末节，针对这些每个技术细节，我们会在以后的每一篇文章中详细介绍。
我们来看下面这张图：
从整体上来讲，可以将微服务体系分为几大部分，黄色部分表示的是负载均衡，绿色部分表示整个微服务，蓝色部分表示基础设施与支持平台，灰色部分表示工程交付规范。
接入层
接入层是整个系统的入口，一般都会使用到服务器负载均衡，服务器端负载均衡由包括DNS负载均衡，IP负载均衡，方向代理负载均衡，服务器端负载均衡技术并不是我们讨论的重点，我们会在其他系列的文章中介绍。
服务网关
服务网关可认为是微服务的看门人，对于服务的使用者，服务网关为其提供统一的访问地址与方式，为调用者封装了访问的细节。因此所有访问的流量都会汇聚到这里，服务网关天然成了微服务的咽喉要塞，统一服务治理等相关操作可以在这里进行处理，那真是一夫当关万夫莫开，比如限流、监控、日志，动态路由，异常处理，灰度发布，鉴权认证，也正是服务网关的重要性，服务网关有着举足轻重的地位。
业务服务
业务服务层中包含两种类型的服务，一种是基础服务，一种聚合服务，基础服务是根据业务功能进行拆分的一个独立服务组件或者公共服务，基础服务的粒度比较小，可认为是一个个的业务原子，每一个原子只关心自己的核心领域。聚合服务的作用主要是两个，第一是：聚合多个基础服务构成更复杂的业务，比如一个复杂的查询需要用的多个基础服务，第二是：适配不同的调用端，返回不同的数据，因为对于同一个业务在不同的调用端上需要的数据不一样，比如同样是商品信息PC端与App需要的数据肯定是不一样的，无论从页面大小，还是流量大小App端需要的数据更精简。
治理服务
服务治理是微服务的关键，如果没有服务治理，微服务只是一个个业务独立的远程接口，不可能构成一个稳定、可用的线上生产系统。在上面提出的那些微服务问题与挑战，通过服务治理大部分问题也都可以解决，服务治理技术构成了微服务的核心组件，这些组件包括：
服务注册与发现：解决服务之间互相找到与发现的问题，隔离服务之间的IP依赖，实现服务的状态监测与管理等。
配置中心：用于管理集群中不同的环境（开发、测试、预生产、生产）配置信息，并实时动态推送配置更新到各个应 用。
熔断机制：解决服务调用链上的洪峰或异常情况，对问题进行必要的隔离，防止系统雪崩现象。
服务网关：为外部调用提供统一的入口，为微服务提供横切的功能，如:鉴权、监控、限流等。
服务监控：对于服务监控，有一个很好的比喻，在手术室或ICU病房都能看到各种各样的设备，它们把病人的各项指标数据，通过数字化的方式呈现在屏幕上，当指标发生异常还会出现警报声音，对病人状态全面的监控，让医生，家属实时了解病人的身体状况，来指导医生采取应对措施。微服务监控也是如此，无论是运维人员，开发人员，测试人员，产品经理，还是大boss，都希望通过服务监控获取他们关心的数据，所以服务监控就是他们的眼睛。
支撑平台
微服务作为一种新的架构风格，涉及的技术不仅仅是微服务组件本身，同时还需要依赖许多“衍生品”，如分布式事务、领域驱动设计，自动化，资源调度，容器化等。而支撑平台为微服务的实施提供某些基础的支撑服务，在某种意义上来说它们并不依赖与微服务而存在，但它们已脚手架的角色支撑着整个微服务大厦的构建。
基础设施
基础设施属于微服务部署运行的载体，我们可以认为是网络、存储、计算，也可以认为是实体机，虚拟机，容器等环境。对于基础设施，无论我们选择自建，托管、租用，还是使用云计算，都需综合考虑数据安全、技术风险，时间成本、投入产出比等诸多因素，同时还要考虑动态扩容，健康检查等问题。当然，基础设施的构建并不是我们要讨论的重点，我们暂且认为它就是一个黑盒子。
工程交付规范
微服务虽然强调敏捷、轻量，自治，但这并不代表我们每个人可以随心所欲，各自为政的去实施服务，必要的契约与规范是很有必要的，规范显著的减少团队沟通，协调成本，降低团队犯错的概率。所以在工程交付方面，团队遵循一套大家认同的规范尤为重要，工程交付规范自始至终贯串整个研发流程。
这一篇文章，我们对微服务整体技术生态做了走马观花式的介绍，目的是让我们先拿到一张关于微服务的地图，对微服务有一个整体的认识。从下篇文章开始，我们将针对这张图上的重要景点进行剖丁解牛式的分析。
2515
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
