服务端：

业务架构演进

随着互联网的发展，用户量越来越大，使用的功能越来越丰富，对于服务端的挑战也越来越大，各种不同的架构方式开始出现来解决这些问题。

对于一个初创产品，用户量少，并发量低，数据量小，往往只需要单应用服务器就可以满足需要，数据库和文件服务器都部署在单个服务器上。比如我们一般日常自己开发一些小的demo app的话，租个简单的云服务器就搞定。

随着访问量的激增，单机服务器总是资源有限，单个数据库的流量也越来越大，这时候出现了数据库性能的瓶颈，于是我们把数据库服务和文件服务拆分出去，单独起一个服务。因为数据库的读写会有影响，一般情况下读的请求远远大于写的请求，我们把数据库读写分离来进行优化。

随着访问量的继续激增，我们发现数据库的性能又有了瓶颈，于是我们把数据库进行分库分表的优化。对于一些访问量特别大的数据，我们又引入了缓存层，一方面来减小数据库的访问压力，一方面也能提供访问的速度。

随着访问量的增加，我们发现用户有一些页面的访问会比较慢，我们发现有些页面是静态的页面，有些页面的数据是实时更新的，于是我们可以采用动静分离的技术，把一些静态资源与后台应用进行分开部署。我们知道在互联网上，用户的网络情况是错综复杂的，如果我们的每次请求都需要直接打到服务端进行处理的话也会非常慢，所以我们又增加了CDN的优化机制，尽量把数据保存在离用户网络最近的地方来进行加速，另一方面，这部分压力直接通过使用缓存，也会减轻服务器端的压力。

随着用户规模和业务量的不断上涨，单个应用服务器也会出现性能瓶颈，于是我们服务器单机开始变成集群，后端开始使用负载均衡的方式来将压力分摊到多个集群。

负载均衡：

在互联网发展呢的今天，我们一般会把多台机器组成一个集群对外提供服务。然而，我们的网站对外提供的访问入口都是一个的，比如 http://www.baidu.com 那么当用户在浏览器输入 http://www.baidu.com 的时候如何将用户的请求分发到集群中不同的机器上呢，这就是负载均衡在做的事情。

随着业务规模的扩大和复杂化，不同的业务区别也越来越大，业务放在一起开发会变的越来越复杂，互相之间的影响也会比较大，各业务的应用情况和量级也是有区别的。针对系统各个业务功能进行拆分，不同的业务团队负责不同的业务模块。我们通过微服务的方式进行了业务领域的拆分，来解决单体业务遇到的问题，包括复杂度过高，开发效率低下，从提交到部署耗时长等问题。 同时为了更好的知道业务逻辑的划分，我们又通过领域驱动设计的方法来指导对微服务如何进行拆分。

什么是微服务

首先，什么是微服务呢？

单体应用

相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：

B/S

但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：

B/S+负载均衡

后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：

B/S+前后端分离

上面3中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：

• 代码臃肿，应用启动时间长；（代码超过1G的项目都有！）

• 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。

• 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；

• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。

• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护

• 一套代码的话，代码merge复杂度急剧增加。

微服务

我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。

在微服务架构之前还有一个概念：SOA（Service-Oriented Architecture）-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与The Open Group的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。

撇开架构先不说，什么样的服务才算微服务呢？

• 单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题（注意是一个业务问题而不是一个接口）。

• 面向服务的。将自己的业务能力封装并对外提供服务，这是继承SOA的核心思想，一个微服务本身也可能使用到其它微服务的能力。 我觉得满足以上两点就可以认为典型的微服务。

微服务典型架构

微服务架构，核心是为了解决应用微服务化之后的服务治理问题。

应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：

服务注册中心

解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：

配置中心

以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：

典型微服务架构

上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：

• 通过熔断、限流等机制保证高可用；

• 微服务之间调用的负载均衡；

• 分布式事务（2PC、3PC、TCC、LCN等）；

• 服务调用链跟踪等等。

微服务框架

目前国内企业使用的微服务框架主要是Spring Cloud和Dubbo（或者DubboX），但是Dubbo那两年的停更严重打击了开发人员对它的信心，Spring Cloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。Spring Cloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面.