SpringCloud（1）——微服务架构概述
一、单体应用架构存在的问题
一个归档包（例如war格式）包含所有功能的应用程序，通常称为单体应用。架构单体应用的方法论，就是单体应用架构。
单体应用比较容易部署、测试，在项目的初期，单体应用可以很好地运行。然而，随着需求不断增加，越来越多人加入开发团队，代码库也飞速地膨胀。慢慢地，单体应用变得越来越臃肿，可维护性、灵活性逐渐降低，维护成本越来越高。
下面是单体应用存在的一些问题：
- 复杂性高
项目模块多，模块边界模糊，依赖关系不清晰，代码质量参差不齐等等，使得整个项目非常复杂。每次修改代码心惊胆战，一个简单的功能或者修改一个bug都会带来隐含的缺陷。 - 技术债务
时间推移、需求变更和人员更迭，逐渐形成应用程序的技术债务。“不坏不修”在软件开发中很常见，单体应用中尤甚。已使用的系统设计或代码难以被修改，因为应用程序中的其他模块可能会以意料之外的方式使用它。 - 部署频率低
代码增加，构建和部署所需时间也会增加。单体应用中，每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。全量部署的方式，耗时、影响范围大、风险高，这使得单体应用项目上线部署的频率较低，进而导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。 - 可靠性差
某个应用BUG，例如死循环、OOM等，可能会导致整个应用的崩溃。 - 扩展能力受限
单体应用只能作为一个整体扩展，无法根据业务模块的需要进行伸缩。例如，有的模块是计算密集型，需要强劲的CPU；有的模块则是IO密集型，需要更大的内存。这些模块部署在一起，就不得不在硬件的选择上做出妥协。 - 阻碍技术创新
单体应用往往使用统一的技术平台或方案解决所有问题，团队中每个成员都必须使用相同的开发语言和框架，要想引入新框架或新技术平台，会非常困难。例如，一个使用Strust2构建、有100万行代码的单体应用，如果想要换用SpringMVC，切换的成本是非常高的。
二、如果解决单体应用架构存在的问题
使用微服务这种架构模式。
三、什么是微服务
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制（通常是HTTP资源API）。这些服务胃药业务能力构建，并且可通过全自动部署机制独立部署。这些服务用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据库存储技术。
从以上描述，微服务架构具有以下特性：
- 每个微服务可独立运行在自己的进程里。
- 一系列独立运行的微服务共同构建起整个系统。
- 每个服务为独立的业务开发，一个微服务只关注某个特定的功能。
- 微服务之间通过一些轻量的通信机制进行通信，例如通过RESTful API进行调用。
- 可以使用不同的语言与数据存储技术。
- 全自动的部署机制。
四、微服务架构的优点和挑战
4.1 微服务架构的优点
- 易于开发和维护
一个微服务只关注一个特定的业务功能，所以它业务清晰、代码量较少。开发和维护单个微服务相对简单，而整个应用是由若干个微服务构建而成，所以整个应用也会被维持在一个可控状态。 - 单个微服务启动较快
单个微服务代码量较少，所以启动会比较快。 - 局部修改容易部署
单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。 - 技术栈不受限
微服务架构中，可以结合项目业务及团队特点，合理地选择技术栈。 - 按需伸缩
可根据需求，实现细粒度的扩展。例如，系统中的某个微服务遇到了瓶颈，可以结合这个微服务的业务特点，增加内存、升级CPU或者增加节点。
4.2 微服务架构面临的挑战
- 运维成本较高
单体架构中，只需要保证一个应用的正常运行。而在微服务中，需要保证几十甚至几百个服务的正常运行和协作，这给运维带来很大的挑战。 - 分布式固有的复杂性
使用微服务构建的是分布式系统，对于分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的挑战。 - 接口调整成本高
微服务间通过接口进行通信。如果修改了某一个微服务的PI，可能所有使用了该接口的微服务都需要做调整。 - 重复劳动
很多服务可能都会使用到相同的功能，而这个功能没有达到分解为一个微服务的程序。这个时候，可能各个服务都会开发这一功能，从而导致代码重复。
五、微服务设计原则
- 单一职责原则
一个单元（类、方法或者服务等）只应关注整个系统功能中单独、有界限的一部分。单一职责原则可以帮助我们更优雅地开发、更敏捷地交付。 - 服务自治原则
每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中，服务是独立的业务单元，应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署，都应当可以独立运行，而不应该依赖其他服务。 - 轻量级通信机制
微服务之间应该通过轻量级的通信机制进行交互。轻量级的通信机制应具备两点：一是体量较轻；二是跨语言、跨平台的。例如REST协议。 - 微服务粒度
微服务的粒度是难点，争论的焦点。应当使用合理的粒度划分，而不是一味地把服务做小。代码量的多少不能作为微服务划分的一句，因为不同的微服务本身的业务复杂性不同，代码量也不同。
以上是 SpringCloud（1）——微服务架构概述 的全部内容， 来源链接： utcz.com/z/516571.html
