微服务架构学习

---

前言

随着业务的需要，服务的架构也在不断演变，从最初的单体应用，到SOA架构，再到现在的微服务，都是架构思想的不断演进。

一、单体应用

1、最简单的B/S架构应用

图示：

2、解决访问量大的问题而增加负载均衡

图示:

负载均衡：

负载均衡算法
负载均衡算法用于确定流量应该被分发到哪一个健康的服务器上，常见的几个算法如下：

• Round Robin — 轮转（Round Robin）意味着服务器会被按顺序地选择，比如负载均衡器会将第一个请求分配给第一个服务器，然后下一个请求分配给第二个服务器，这样分配下去分配完一轮之后回到开头分配给第一个服务器（操作系统调度算法复习一下）。这种方式比较适合各服务器处理能力相同而且每个业务处理量差不多的时候。
• Least Connections — 最少连接（Least Connections）这个算法意味着负载均衡器会选择当前连接最少的服务器。
• IP hash — 在这个算法下，负载均衡器根据请求源的IP来决定分发给哪个服务器。这个方法保证了一个特定的用户会一直访问相同的服务器。
  其他还有一些不算太常见的算法，比如Url hash、Random等。

负载均衡双机热备（Hot standby）：解决负载均衡器自身单点故障隐患问题
。图示：

3、将静态资源文件提取出，通过CDN等技术进行加速，从而提高应用的整体响应；

图示：

CDN技术：
内容分发网络（Content Delivery Network, CDN），是在现有网络中增加一层新的网络架 构。 CDN 将源站的内容发布和传送到最靠近用户的边缘地区，使用户可以就近访问想要的内 容，从而提高用户访问的响应速度。 CDN 的基本原理是依靠放置在各地的缓存服务器，通过全局调度以及内容分发等功能模 块，将用户需要的那部分内容部署到最贴近用户的地方，将原本低效、不可靠的四网络转变成高效、可靠的智能网络，满足用户对内容访问质量的更高要求， 改善互联网网络拥塞问题， 提高用户访问网站的响应速度。
CDN 的构成元素为内容 (Content）、分发（Delivery） 以及网 络（Network）。

单体应用的缺点：

• 代码臃肿，应用启动时间长；
• 回归测试周期长，修复一个小小bug可能都需要对所有关键业务进行回归测试。
• 应用容错性差，某个小小功能的程序错误可能导致整个系统宕机；
• 伸缩困难，单体应用扩展性能时只能整个应用进行扩展，造成计算资源浪费。
• 开发协作困难，一个大型应用系统，可能几十个甚至上百个开发人员，大家都在维护一套代码的话，代码merge复杂度急剧增加。

二、SOA架构

SOA 是一种在计算环境中设计、开发、部署和管理离散逻辑单元（服务）模型的方法。

SOA特点：

• 服务尽可能的放在一起；
• 水平分多层；
• 按层级划分不同部门的组织负责；
• 按粗粒度的方式划分，存在较复杂的组件；
• 业务逻辑横跨多个业务领域；
• 企业服务产总线（ESB）充当了服务之间通信的角色。

实现方面：

• 企业级，自顶向下开展实施；
• 服务由多个子系统组成，粒度大；
• 企业服务总线，集中式的服务架构；
• 集成方式复杂（ESB/WS/SOAP）；
• 单块架构系统，相互依赖，部署复杂。

三、微服务

微服务的思想：

• 单一职责的。一个微服务应该都是单一职责的，这才是“微”的体现，一个微服务解决一个业务问题。
• 面向服务的。将自己的业务能力封装并对外提供服务，一个微服务本身也可能使用到其它微服务的能力。

由传统服务架构演变为微服务需要解决的问题：

1、多个服务带来的服务发现问题

解决路径：服务注册中心

所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：

2、分布式部署带来的服务配置管理的问题

解决路径：配置中心

演变出进一步的微服务架构：

3、多个服务带来的授权等问题

解决路径：服务网关

演变后的微服务架构：

其他：

• 通过熔断、限流等机制保证高可用；
• 微服务之间调用的负载均衡；
• 分布式事务（2PC、3PC、TCC、LCN等）；
• 服务调用链跟踪等等。

微服务的优势：

• 加速做好面市准备。由于开发周期缩短，微服务架构有助于实现更加敏捷的部署和更新。
• 高度可扩展。随着某些服务的不断扩展，您可以跨多个服务器和基础架构进行部署，充分满足自身需求。
• 出色的弹性。只要确保正确构建，这些独立的服务就不会彼此影响。这意味着，一个服务出现故障不会导致整个应用下线，这一点与单体式应用模型不同。
• 易于部署。相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，所以您无需为它们的部署操心。虽然对部署时的协作要求更高（服务网格可以辅助这一过程），但之后能获得巨大回报。
• 易于访问。由于大型应用被拆分成了多个小型服务，所以开发人员能够更加轻松地理解、更新和增强这些服务，从而缩短开发周期（尤其是在搭配使用敏捷的开发方法时）。
• 更加开放。由于使用了多语言 API，所以开发人员可以根据需要实现的功能，自由选用最适合的语言和技术。

总结

任何新技术的出现都是为了解决原有技术无法解决的需求，微服务的出现就是解决原来单体应用架构已经无法满足当前互联网产品的技术需求的问题。