架构杂谈《二》

灰太狼 2021-12-04 05:27 244阅读 0赞

## **架构杂谈《二》** ##

### **服务化到微服务** ###

**1****、微服务的产生**

随着互联网企业的不断发展，海量用户发起的大规模、高并发请求是企业不得不面对的，上一篇 [架构杂谈《一》][Link 1]杂谈的SOA服务化系统能够分解任务，让每个服务更简单、职责单一、更易于扩展。但无论是Web Service 还是ESB，都有时代遗留下的问题。

**Web Service****：**

1）依赖中心化的服务发现机制

2）使用SOAP通讯协议，通常使用XML格式来序列化通信数据，XML格式的数据冗余太大，协议太重

3）服务化管理和治理设施并不完善

**ESB****：**

**　　　**1）ESB 虽然是SOA实现的一种方式，却更多地体现了系统集成的便利性，通过统一的服务总线将各个服务组合在一起

2）组合在ESB上的服务本身有可能是一个臃肿的服务

3）系统内部的复杂性仍然存在。ESB试图通过总线来掩盖系统内部的复杂性

4）对于总线本身中心化的管道模型，系统变更时影响的范围会随之扩大

出现问题解决问题是人类进步的阶梯，对于软件架构也是一样，近年来服务架构设计得到了进一步的演化和发展，微服务架构已经出现在不同公司的讨论、设计和实践中，经过市场检验的东西肯定会被大家所接受。

微服务架构提倡将软件应用设计成多个可独立开发、配置、运行和维护的子服务，子服务之间通过良好的接口定义通信机制，通常使用RESTful风格的API形式来通信。因为RESTful 风格的 API 通常是在 HTTP 或者 HTTPS 通道上传输 JSON 格式的数据来实现的， HTTP协议有跨语言、跨异构系统的优点， 当然也可通过底层的二进制协议、消息队列协议等进行交互。这些服务不需要中心化的统一管理，每个服务的功能可自治，并且可由不同的语言、系统和平台实现 。

微服务架构致力于松耦合和高内聚的效果，与SOA和ESB相比，不再强调服务总线和通信机制的多样性，通常通过RESTful 风格的API和轻量级的消息通信协议来完成。

微服务架构并不是为了拆分而拆分，真正的目的是通过对微服务进行水平扩展解决传统的单体应用在业务急剧增长时遇到的问题，而且由于拆分的微服务系统中专业的人做 专业的事，人员和项目的职责单一、低藕合、高内聚，所以产生问题的概率就会降到最小。

**2****、微服务与单体的对比**

**![562098-20190711204729454-1840680140.png][]**

（微服务架构图）

从上图可以得到：

1）  微服务把每一个职责单一的功能放在一个独立的服务中

2）  每个服务运行在一个单独的进程中

3）  每个服务有多个实例在运行，每个实例可以运行在容器化平台内

4）  每个服务有自己的数据存储，实际上，每个服务应该有自己独享的数据库、缓存、消息队列等

5）  每个服务都可根据性能需求独立地水平伸缩

![562098-20190711204902091-653667981.png][]

（单体架构图）

通过对比，可以得到传统单体架构的特点：

1）  传统单体架构将所有模块化组件糅合后运行在同一个服务的进程中

2）  某个模块发生变更时，需要将所有的模块编译、打包上线

3）  久而久之，模块间的依赖将会不清晰，互相耦合，互相依赖成为常态

通过将两种架构对比来看，微服务架构更加的灵活并且可水平伸缩，可以让专业的人干专业的事。

**3****、微服务与****SOA****服务的对比**

微服务架构的一些特点与 SOA 服务化架构相似， 事实上微服务架构与 SOA 服务化架构并不冲突，它们一脉相承，微服务架构是服务化架构响应特定历史时期的使用场景的延续，是服务化进行升华井落地的一种实现方式。 SOA 服务化的理念在微服务架构中仍然有效，微服务在 SOA 服务化的基础上进行了演进和叠加，形成了适合现代化应用场景的一个方法论。

经过几十年互联网的高速发展，以及敏捷、持续集成、持续交付、DevOps、云技术等的深入人心，服务架构的开发、测试、部署以及监控等，相比SOA已经发生大的变化。

1）  SOA 服务化涉及的范围更广一些，强调不同的异构服务之间的协作和契约 ，并强调有效集成、业务流程编排、历史应用集成等，典型代表为 Web Service 和 ESB

2）  微服务使用一系列的微小服务来实现整体的业务流程，目的是有效地拆分应用，实现敏捷开发和部署，在每个微小服务的团队里，减少了跨团队的沟通，让专业的人做专业的事，缩小变更和法代影响的范围，并达到单一微服务更容易水平扩展的目的

3）  微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容、缩容的 Docker 技术来实现自动化的容器管理 ， 每个微服务运行在单一的进程内，微服务中的部署互相独立 、 互不影响。

4）  SOA 服务化通常将多个业务服务通过组件化模块方式打在一个包里，然后统一部署在一个应用服务器上。

6）  SOA 对粒度没有要求 ， 在实践中服务通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。

相比SOA的服务实现方式，微服务更具灵活性、可实施性以及可扩展性，其强调的是一种独立测试、独立部署、独立运行的软件架构模式。对于微服务的概念而言，它是SOA的一个子集，而对于其实现方式而言，它是一种更符合现代化互联网发展趋势的实践，是一种更容易帮助企业或组织有效并成功实施的服务架构。

**总结**

最后让我来总结下微服务架构的主要特点

*  将传统单体应用拆分成网络服务，来实现模块化组件 。
 *  根据微服务架构的服务划分来分组职能团队，减少跨团队的沟通 。
 *  每个服务对应一个团队，团队成员负责开发、测试、运维和运营 ，开发后在团队内运维和运营，不需要交付给其他团队。
 *  去中 心化、 去 SOA 服务化的中 心服务治理和去企业服务总线 。
 *  微服务重视服务的合理拆分、分层和构造，可建设自动化持续发布平台，井进行敏捷开发和部署。

** 说明：**

1、文中的图都来自于百度图片

2、参考书籍：《分布式服务架构：原理、设计与实战》

3、如有不合适的地方请反馈。综合后更改。

![562098-20190711205010820-1049666088.png][]

转载于:https://www.cnblogs.com/haoxiaozhang/p/11172670.html

[Link 1]: https://www.cnblogs.com/haoxiaozhang/p/11158203.html
[562098-20190711204729454-1840680140.png]: /images/20211204/dbb893cc60914739b26ff24d689596cd.png
[562098-20190711204902091-653667981.png]: /images/20211204/324a38894d9d414eb5f73cdc525de523.png
[562098-20190711205010820-1049666088.png]: /images/20211204/03ffe19227c94351abad08a81d9da275.png