微服务现在已经是各种互联网应用首选的云架构组件，无论是 BAT 还是 滴滴、美团 ，微服务都是重要的一环。

相对于微服务，传统应用架构有以下缺点：

1. 业务代码混杂，团队成员职责边界不清，团队协作体验不佳，开发效率低下。

传统应用架构中，各个业务模块代码都存在于同一个应用当中，各个业务模块之间交互逻辑复杂，代码统统混在一起，难免出现要去别人代码里改代码的情况

2. 代码耦合度高，日趋臃肿，难以重构，维护成本越来越高。

感受过被F12支配的恐惧吗？

3. 容错能力弱，单点故障引发全局崩溃。

4.无法针对热点业务增加资源，造成浪费。

 

典型的微服务架构概览

 

微服务架构按照功能和业务将应用程序分离成若干个部分，使各个部分之间松绑。一个典型的简单微服务架构至少有以下几个部分：

1. UI 层：即前端视觉层，包括 web 端网页、手机APP以及PC客户端。

2. 网关层：网关层类似我们家里用的路由器，可以将入站请求重定向到目标为服务，并将站内的微服务进行整合打包输出到站外。UI层一般会通过 HTTP/HTTPS 协议访问网关向公网暴露的接口。此外，网关还应该具有鉴权的功能。

3. 反向代理：反向代理（Reverse Proxy）方式是指以来接受internet上的连接请求，然后将请求转发给内部网络上的服务器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。通过在网络各处放置反向代理所构成的在现有的互联网基础之上的一层智能，CDN系统能够实时地根据和各节点的连接、负载状况以及到用户的距离和响应时间等综合信息将用户的请求重新导向离用户最近的服务节点上。

4. 微服务集群：根据需求不同，微服务集群中会包含至少1个微服务实例，通过负载平衡将请求分配到每个实例上。如果使用Docker容器服务，则微服务集群中至少包含一个Docker实例，配合负载平衡，我们可以动态的决定要启用多少个Docker实例，并在不需要的时候销毁冗余的实例，提供完全自动化的弹性计算能力。

 5. 互操作性：微服务之间一般选用 HTTP/HTTPS 或者 RPC 作为互操作协议，使用JSON或者ProtoBuf序列化对象。由于微服务都部署在同一个内网之中，性能损耗几乎可以忽略不计，如果选用RPC + ProtoBuf 的交互方案，延迟会更低。

微服务架构还有一些不足：

1. 微服务首先强调的是服务规模小，便于服务的伸缩和扩展，但是这也会导致服务碎片化，对人员管理提出了挑战。

2. 微服务是一个分布式的系统，每一个微服务都有自己的数据库，虽然在一定程度上增加了应用程序的整体可靠性，但是也不可避免的带来大量冗余数据。

3. 随着服务规模增长，微服务的实例数量将会飞速增长，比如美国著名的在线电视网站 NetFlix（网飞）有大约600个微服务实例，而且这个数量还在不断地增长。微服务的运维程序将不断攀升。

4. 对于一些业务逻辑十分复杂的业务，可能一次调用便与十几甚至数十个接口相关，为了满足性能需求，我们不得不引入通知系统来异步处理一些内容。异步处理紧接着就带来了数据一致性问题。

 

以上便是本章内容，如有稍可愚目者，还请不吝赐教。

下一章我将会通过一个例子分析同步执行和异步执行的优劣。