.NET Core 实践：微服务架构的优势

微服务如今已是各类互联网应用首选的云架构组件，不管是 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. 对于一些业务逻辑十分复杂的业务，可能一次调用便与十几甚至数十个接口相关，为了知足性能需求，咱们不得不引入通知系统来异步处理一些内容。异步处理紧接着就带来了数据一致性问题。

 

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

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