「系统架构」微服务探究之初识微服务
「系统架构」微服务探究之初识微服务
前言
在传统的开发中，我们通常是将所有的功能打包在一起，然后统一部署在一个JEE容器（Tomcat，JBoss，WebLogic）里，包含了 DO/DAO，Service，UI等所有逻辑。如下图所示：
这种开发方式虽然操作简单，代码重用率高，没有分布式的管理和调用消耗，但是由于代码功功能耦合在一起，通常是牵一发动全身，一个微小的问题，都可能导致整个应用挂掉。这对于大型应用来说，是很不可行的。因此，有人提出能不能将每一个小的服务独立开来，分别部署维护呢？如产品服务独立成一块，订单服务独立成一块，用户服务也独立成一块。这样，每一个服务之间都不会有高耦合性，后期维护升级也更加方便。
是的，将每一个服务独立部署分开维护，的确可以解决传统开发中的高耦合性，但是我们也要考虑在传统的开发方式中所有的服务都是本地的，UI可以直接调用，现在按功能拆分成独立的服务，跑在独立的服务器或进程中，客户端UI如何互相访问呢？
后台有N个服务，前台就需要记住管理N个服务，一个服务下线/更新/升级，前台就要重新部署，这明显不服务我们 拆分的理念，特别当前台是移动应用的时候，通常业务变化的节奏更快。
另外，N个小服务的调用也是一个不小的网络开销。还有一般微服务在系统内部，通常是无状态的，用户登录信息和权限管理最好有一个统一的地方维护管理（OAuth）。
因此，基于这些考虑，在上面的基础上，有人又提出加入API网关层，用它来处理以下问题：
- ① 提供统一服务入口，让微服务对前台透明
- ② 聚合后台的服务，节省流量，提升性能
- ③ 提供安全，过滤，流控等API管理功能
至此，一个简单的微服务架构就诞生了。
服务之间如何通信
将每一个服务独立部署后，肯定不能像传统开发中使用类库嵌套的方式调用其他服务。在微服务架构中，服务与服务之间的通信通常有两种方式：
- ①同步调用
- ②异步调用
其中，同步调用又包括RPC方式和REST方式。
一般同步调用比较简单，一致性强，但是容易出现调用问题，性能体验上也会差些，特别是调用层次多的时候。
而异步调用在分布式系统中有特别广泛的应用，如异步消息，它既能降低调用服务之间的耦合，又能成为调用之间的缓冲，确保消息积压不会冲垮被调用方，同时能保证调用方的服务体验，继续干自己该干的活，不至于被后台性能拖慢。不过需要付出的代价是一致性的减弱，需要接受数据最终一致性。还有就是后台服务一般要实现幂等性，因为出于性能的考虑，消息的发送一般会有重复（保证消息的被收到且仅收到一次对性能是很大的考验）。最后就是必须引入一个独立的broker，如 果公司内部没有技术积累，对broker分布式管理也是一个很大的挑战。
服务注册
在微服务架构中，一般每一个服务都是有多个拷贝的，每一个拷贝之间采用负载均衡的方式参与业务处理。一个服务随时可能下线，也可能为应对临时访问压力增加新的服务节点。那服务之间如何相互感知？多个服务如何管理呢？
这就设计到服务注册了。服务注册通常有客户端方式和服务端方式两种。不过其基本原理都是通过zookeeper等类似技术做服务注册信息的分布式管理。当服务上线时，服务提供者将自己的服务信息注册到ZK（或类似框架），并通过心跳维持长链接，实时更新链接信息。服务调用者通过ZK寻址，根据可定制算法， 找到一个服务，还可以将服务信息缓存在本地以提高性能。当服务下线时，ZK会发通知给服务客户端。
服务异常处理
前面提到，为避免传统开发方式把所有鸡蛋放在同一个篮子里，一荣俱荣，一损俱损的问题，人们转而采用服务独立部署的方式，但独立部署有一个很大的风险就是网络是不可靠的，即网络可能出现故障，如果这一块没有特别的保障，采用微服务架构结局肯定也是噩梦。那微服务如何保证整体业务链路不受网络的影响或者把受到的影响降到最低呢？关于这一方面，微服务主要采用以下几个手段：
- 重试机制：多试几次
- 限流：减少到该服务的请求
- 熔断机制：关闭该服务与其他服务之间的联系
- 负载均衡：将指定请求分配到指定服务
- 降级（本地缓存）：暂时关闭某些无关服务