1.服务网关
将后端的多个服务变成黑盒，对外只暴露唯一的服务网关，网关根据路由配置将外面访问的请求转发到具体的某一个服务上。一些成熟的网关组件其实除了路由功能以外，还集成了诸如，权限验证，服务注册/发现/负载均衡，熔断,限流和降级的功能。
2.权限验证
若想要请求后端的微服务，需要对请求进行相应验证，第一次访问时根据相应的授权凭证（例如:用户名/密码），到授权服务那里进行权限鉴定，若鉴定成功，根据相应的加盐加密算法会生成一个Token串，下次请求再来时需要携带此Token串，授权服务会对Token串进行解密校验，该Token串是唯一的，并且可以标识用户的身份以及存储一些profile信息。
3.服务注册/发现/负载均衡
每个微服务启动需要到注册中心那里去注册自己，将自己的地址以及服务名告诉注册中心，若要实现基于性能的负载均衡，同时还要上传自己的CPU,内存等信息给注册中心。当需要消费服务时需要先到注册中心那里根据服务名来获取提供服务的服务地址。每个服务一般会注册多个实例，一般会根据一些策略（wrr，round robin等）来挑选具体某一个服务实例，注册中心需服务实例会保持着心跳机制，若服务实例挂掉就会从注册中心消失，因为注册中心没有继续收到服务传过来的心跳信息，则会判定该服务死亡，那么就会从服务列表中将其删除。
4.限流/熔断/降级
熔断其实类似日常生活中的“保险丝”，一个用户请求的调用，在微服务内部可能是多个服务之间的连环调用，若其中一个或几个服务产生了系统瓶颈，就会导致超时，这样会阻碍整体调用链的调用进度，从而导致整个系统连接数过多，造成系统瘫痪，那么熔断要做的就是当发现某一服务的错误、超时、负载，达到某一指标时候来拦截后续的请求。当服务产生熔断后，那么就需要对服务进行降级，降级可以立即给用户一个返回，及时的返回空白内容或是错误信息。顾名思义限流就是限制请求的qps，将请求的数量控制在该服务可以接受的范围内。
5.消息中心
它在微服务中起到了很多作用，利用消息的订阅发布可以解决分布式最终一致性的问题，而且也可以实现服务之间的异步调用，让服务与服务之间进行解耦。
6.分布式跟踪
分布式微服务中，对外暴露的用户请求，在微服务内部可能会是服务之间互相调用多次的结果，某一个请求超时或出现错误，我们都需要了如指掌。目前一些开源组件也有很好的实现，主要就是根据链表的数据结构，对整个调用链进行唯一的TraceID标识，每个调用节点也有自己的SpanID和上一个调用节点的ParentID,ParentID为Null时就是起始调用节点。每个节点会存储相应的信息，包括客户端发起请求时间，服务端收到请求的时间等等。默认这些信息都会存入内存中，也可进行数据持久化，然后通过WebUI查看整个调用链的详细信息，便于分析。
7.REST/RPC/序列化
微服务中，无论是对外暴露的接口，还是服务之间互相调用的接口，都离不开通讯协议与序列化。通讯协议有我们所熟知的http, soap, websocket,rpc等，序列化有json,xml,protobuf,bytes,text等。对外提供服务的接口一般都会使用http+json的方式，服务内部之间调用的话通常会使用rpc+prtobuf的方式，rcp是二进制的，它比http传输性能要高，而且protobuf的序列化/反序列化性能同样比json的要高，http是可以跨语言的，没有语言的约束，但rpc对语言是有一定约束的，虽然如此但目前有很多成熟的rpc框架以样也可以实现跨语言。
8.统一配置管理
微服务自然会有很多个小服务，若每个服务都有自己的一些配置，那么运维起来简直就是噩梦，所以统一的配置管理是必要的，目前有一些成熟的开源的框架都可以做到，有了配置中心，我们就可以根据不同环境应用不同的配置，多种配置都可以存到git中，进行版本控制，根据路径规则匹配不用的配置。同样也可以支持热更新，无需重启服务。
9.CI/CD
持续集成与持续交付，快速的迭代是微服务所需的，服务多了本来就复杂，而且服务之间的接口变更和新功能的添加都会比较容易造成互相制约，若不采用持续集成与交付的话，那项目进度就会被拉的很长，目前CI/CD比较好的实现方式就是，git + jenkins + docker, git负责源码版本控制，jenkins进行自动化的打包，编译，测试，部署，这里部署我们可以使用docker容器，也可以不使用，直接放到物理机上运行，主要还是看项目的底层架构
10.日志
分布式的微服务，每个服务都会产生日志，那么当要分析问题时我们肯定不会每台机器的去查看日志，这也会是一场噩梦，好的办法就是收集聚合所有服务的日志，然后汇总到一起，根据服务名，TraceID,IP等一些关键字进行过滤来找出有用的日志。ELK就是解决此类日志问题的利器。
11.监控
单点应用定位问题相对来说是比较好定位的，但是服务多了，微服务之间互相的接口交互，哪个节点出现了问题都需要快速定位到出现问题的点，若微服务运行在容器当中，我们同样要考虑容器的监控，以及app的日志监控，同样还有app的业务监控。
以上已经把微服务的大部分功能模块做了一个简明扼要的阐述，那么下面我们就来仔细聊聊微服务的监控。
微服务的监控
对于微服务系统来说，相对比较复杂的是监控，容器编排，还有日志收集，容器编排目前有很好的实现，比如Kubernetes, Swarm, Mesos,等等，这些都解决了容器的编排问题，这里之所以提到容器编排，是因为微服务的落地比较好的实现方式就是运行在容器当中，多亏了这些开源组件的存在，很多微服务所要考虑的问题都被集成到这些平台中了。那么对于这种多说上千万个虚拟容器的大集群来说，监控到底怎么实现呢？