权威架构师穷思苦索总结——必会的10个微服务架构设计要点！

近来，几乎人人都在谈论微服务。微服务之因此火热也是由于相对以前的应用开发方式有不少优势，如更灵活、更能适应如今需求快速变动的大环境等。本文将介绍微服务架构设计中的一些要点。

微服务架构设计时有哪些要点呢？先看下图是 Spring Cloud 的整个生态。

下图是完美实现微服务的十二原则：

接下来，细说微服务架构设计中不得不知的十大要点。 给你们推荐一个程序员学习交流群：702895049。群里有分享的视频，还有思惟导图 群公告有视频，都是干货的，你能够下载来看。主要分享分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频。

 负载均衡 + API 网关 

在实施微服务的过程当中，难免要面临服务的聚合与拆分。 当后端服务的拆分相对比较频繁的时候，做为手机 App 来说，每每须要一个统一的入口，将不一样的请求路由到不一样的服务，不管后面如何拆分与聚合，对于手机端来说都是透明的。

 有了 API 网关之后，简单的数据聚合能够在网关层完成，这样就不用在手机 App 端完成，从而手机 App 耗电量较小，用户体验较好。

 有了统一的 API 网关，还能够进行统一的认证和鉴权，尽管服务之间的相互调用比较复杂，接口也会比较多。 API 网关每每只暴露必须的对外接口，而且对接口进行统一的认证和鉴权，使得内部的服务相互访问的时候，不用再进行认证和鉴权，效率会比较高。

 有了统一的 API 网关，能够在这一层设定必定的策略，进行 A/B 测试，蓝绿发布，预发环境导流等等。 API 网关每每是无状态的，能够横向扩展，从而不会成为性能瓶颈。 

无状态化与独立有状态集群

x` 影响应用迁移和横向扩展的重要因素就是应用的状态。

无状态服务，是要把这个状态往外移，将 Session 数据，文件数据，结构化数据保存在后端统一的存储中，从而应用仅仅包含商务逻辑。 

状态是不可避免的，例如 ZooKeeper，DB，Cache 等，把这些全部有状态的东西收敛在一个很是集中的集群里面。 整个业务就分两部分，一个是无状态的部分，一个是有状态的部分。 

无状态的部分能实现两点： 跨机房随意地部署，也即迁移性。 弹性伸缩，很容易地进行扩容。 有状态的部分，如 ZooKeeper，DB，Cache 有本身的高可用机制，要利用到它们本身高可用的机制来实现这个状态的集群。

 虽然说无状态化，可是当前处理的数据，仍是会在内存里面的，当前的进程挂掉数据，确定也是有一部分丢失的。

 为了实现这一点，服务要有重试的机制，接口要有幂等的机制，经过服务发现机制，从新调用一次后端服务的另外一个实例就能够了。

 给你们推荐一个程序员学习交流群：702895049。群里有分享的视频，还有思惟导图 群公告有视频，都是干货的，你能够下载来看。主要分享分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频。 

 数据库的横向扩展

数据库是保存状态，是最重要的也是最容易出现瓶颈的。

有了分布式数据库可使数据库的性能随着节点增长线性地增长。  

分布式数据库最最下面是 RDS，是主备的，经过 MySQL 的内核开发能力，咱们可以实现主备切换数据零丢失。

 因此数据落在这个 RDS 里面，是很是放心的，哪怕是挂了一个节点，切换完了之后，你的数据也是不会丢的。 再往上就是横向怎么承载大的吞吐量的问题，上面有一个负载均衡 NLB，用 LVS，HAProxy，Keepalived，下面接了一层 Query Server。 

Query Server 是能够根据监控数据进行横向扩展的，若是出现了故障，能够随时进行替换的修复，对于业务层是没有任何感知的。 另一个就是双机房的部署，DDB 开发了一个数据运河 NDC 的组件，可使得不一样的 DDB 之间在不一样的机房里面进行同步。  

这时候不但在一个数据中内心面是分布式的，在多个数据中内心面也会有一个相似双活的一个备份，高可用性有很是好的保证。

 缓存

在高并发场景下缓存是很是重要的。要有层次的缓存，使得数据尽可能靠近用户。数据越靠近用户能承载的并发量也越大，响应时间越短。

 在手机客户端 App 上就应该有一层缓存，不是全部的数据都每时每刻从后端拿，而是只拿重要的，关键的，时常变化的数据。

 尤为对于静态数据，能够过一段时间去取一次，并且也不必到数据中心去取，能够经过 CDN，将数据缓存在距离客户端最近的节点上，进行就近下载。

 有时候 CDN 里面没有，仍是要回到数据中心去下载，称为回源，在数据中心的最外层，咱们称为接入层，能够设置一层缓存，将大部分的请求拦截，从而不会对后台的数据库形成压力。

 若是是动态数据，仍是须要访问应用，经过应用中的商务逻辑生成，或者去数据库读取，为了减轻数据库的压力，应用可使用本地的缓存，也可使用分布式缓存。

 如 Memcached 或者 Redis，使得大部分请求读取缓存便可，没必要访问数据库。 固然动态数据还能够作必定的静态化，也即降级成静态数据，从而减小后端的压力。

 服务拆分与服务发现 

当系统扛不住，应用变化快的时候，每每要考虑将比较大的服务拆分为一系列小的服务。

 这样第一个好处就是开发比较独立，当很是多的人在维护同一个代码仓库的时候，每每对代码的修改就会相互影响。

 经常会出现我没改什么测试就不经过了，并且代码提交的时候，常常会出现冲突，须要进行代码合并，大大下降了开发的效率。

 另外一个好处就是上线独立，物流模块对接了一家新的快递公司，须要连同下单一块儿上线，这是很是不合理的行为。 我没改还要我重启，我没改还让我发布，我没改还要我开会，都是应该拆分的时机。

 再就是高并发时段的扩容，每每只有最关键的下单和支付流程是核心，只要将关键的交易链路进行扩容便可，若是这时候附带不少其余的服务，扩容既是不经济的，也是颇有风险的。

 另外的容灾和降级，在大促的时候，可能须要牺牲一部分的边角功能，可是若是全部的代码耦合在一块儿，很难将边角的部分功能进行降级。 

固然拆分完毕之后，应用之间的关系就更加复杂了，于是须要服务发现的机制，来管理应用相互的关系，实现自动的修复，自动的关联，自动的负载均衡，自动的容错切换。

 服务编排与弹性伸缩

服务拆分之后，服务的数量很是多，若是全部的配置都以配置文件的方式放在应用本地的话，很是难以管理。 能够想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，于是须要有统一的配置中心，来管理全部的配置，进行统一的配置下发。

 在微服务中，配置每每分为如下几类：

 一类是几乎不变的配置，这种配置能够直接打在容器镜像里面。

 第二类是启动时就会肯定的配置，这种配置每每经过环境变量，在容器启动的时候传进去。 

第三类就是统一的配置，须要经过配置中心进行下发。

例如在大促的状况下，有些功能须要降级，哪些功能能够降级，哪些功能不能降级，均可以在配置文件中统一配置。 

统一日志中心

一样是进程数目很是多的时候，很难对成千上百个容器，一个一个登陆进去查看日志，因此须要统一的日志中心来收集日志。 为了使收集到的日志容易分析，对于日志的规范，须要有必定的要求，当全部的服务都遵照统一的日志规范的时候，在日志中心就能够对一个交易流程进行统一的追溯。 例如在最后的日志搜索引擎中，搜索交易号，就可以看到在哪一个过程出现了错误或者异常。 

 熔断，限流，降级

服务要有熔断，限流，降级的能力，当一个服务调用另外一个服务，出现超时的时候，应及时返回，而非阻塞在那个地方，从而影响其余用户的交易，能够返回默认的托底数据。  

当一个服务发现被调用的服务，由于过于繁忙，线程池满，链接池满，或者老是出错，则应该及时熔断，防止由于下一个服务的错误或繁忙，致使本服务的不正常，从而逐渐往前传导，致使整个应用的雪崩。 

当发现整个系统的确负载太高的时候，能够选择降级某些功能或某些调用，保证最重要的交易流程的经过，以及最重要的资源所有用于保证最核心的流程。 

还有一种手段就是限流，当既设置了熔断策略，又设置了降级策略，经过全链路的压力测试，应该可以知道整个系统的支撑能力。

 于是就须要制定限流策略，保证系统在测试过的支撑能力范围内进行服务，超出支撑能力范围的，可拒绝服务。

 当你下单的时候，系统弹出对话框说 “系统忙，请重试”，并不表明系统挂了，而是说明系统是正常工做的，只不过限流策略起到了做用。 

 全方位的监控

当系统很是复杂的时候，要有统一的监控，主要有两个方面，一个是是否健康，一个是性能瓶颈在哪里。 当系统出现异常的时候，监控系统能够配合告警系统，及时地发现，通知，干预，从而保障系统的顺利运行。 当压力测试的时候，每每会遭遇瓶颈，也须要有全方位的监控来找出瓶颈点，同时可以保留现场，从而能够追溯和分析，进行全方位的优化。

 给你们推荐一个程序员学习交流群：702895049。群里有分享的视频，还有思惟导图 群公告有视频，都是干货的，你能够下载来看。主要分享分布式架构、高可扩展、高性能、高并发、性能优化、Spring boot、Redis、ActiveMQ、Nginx、Mycat、Netty、Jvm大型分布式项目实战学习架构师视频。