微服务

最新推荐文章于 2020-07-06 09:26:01 发布

spongeboblz

最新推荐文章于 2020-07-06 09:26:01 发布

阅读量306

点赞数 1

分类专栏： springcloud

本文链接：https://blog.csdn.net/u014296316/article/details/80474052

版权

springcloud 专栏收录该内容

18 篇文章 0 订阅

订阅专栏

单体架构

一个归档包包含了应用所有功能的应用程序，我们通常称之为单体应用。
架构单体应用的架构风格，我们称之为单体架构，这是一种比较传统的架构风格。
在单体架构，我们的所有程序代码都在一个war包内。在规模较小，功能数、吞吐量都不高的时候是很适宜的。但是随着系统规模的扩大，单体架构所暴露出来的问题也就越多，实践证明它也不适用于大型项目的开发。单体架构主要问题有以下几点。

单体架构的问题

1. 复杂性逐渐变高

随着开发模块及功能不断的增多，各个模块与功能之间的边界也越来越模糊，各个service相互调用，倘若一个模块需要修改往往牵一发而动全身。可以说单体架构开发及后期维护的难度同已有的功能模块数成一种正相关的关系。

2. 技术债务逐渐上升

随着时间推移、需求变更和人员更迭，会逐渐形成应用程序的技术债务，并且越积越多。“不坏不修（Not broken，don’t fix）”，这在软件开发中非常常见，在单体应用中这种思想更甚。已使用的系统设计或代码难以修改，因为应用程序的其他模块可能会以意料之外的方式使用它。

3. 部署频率低

随着代码的增多，构建和部署的时间也会增加。而在单体应用中，每次功能的变更或缺陷的修复都会导致我们需要重新部署整个应用。全量部署的方式耗时长、影响的范围大、风险高，这使得单体应用项目上线部署的频率较低。而部署频率低又导致两次发布之间会有大量的功能变更和缺陷修复，出错概率比较高。

4. 阻碍技术创新

单体架构中如何扩展都得基于当前使用的技术基础，随着时间一推移，很多新的技术就无法使用，要使用只能将整个项目进行重构。

5. 扩展能力受限

单体应用只能作为一个整体进行扩展，无法结合业务模块的特点进行伸缩。例如，应用中有的模块是计算密集型的，它需要强劲的CPU；有的模块则是IO密集型的，需要更大的内存。由于这些模块部署在一起，我们不得不在硬件的选择上做出妥协。

微服务

Martin Fowler：简而言之，微服务架构风格这种开发方法，是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中，并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建，并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写，并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
####微服务具备的特性

每个微服务可独立运行在自己的进程里
一系列独立运行的微服务共同构建起了整个系统
每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理、用户管理等
微服务之间通过一些轻量的通信机制进行通信，例如通过REST API或者RPC的方式进行调用
微服务之间通过一些轻量的通信机制进行通信，例如通过REST API进行调用；
可以使用不同的语言与数据存储技术；
全自动的部署机制。

微服务优点

易于开发和维护
启动较快
局部修改容易部署
技术栈不受限
按需伸缩

微服务带来的挑战

运维要求较高
分布式的复杂性
接口调整成本高
重复劳动

微服务设计原则

单一职责原则
服务自治原则:服务是实体,它们独立地配置、更新和管理
轻量级通信原则
接口明确原则:每个服务的对外接口应该明确定义，并尽量保持不变。

个人理解

以上绝大部分都是抄的，本来想按自己的意思写点，发现写的还不如抄的好。写点个人感受吧，首先就是觉得微服务的架构就是为了解决单体架构的一些痛点而提出来的。单体架构具有很强的实时性，这种实时性限制了单体架构最好是只进行极少数次的再开发，这样是比较舒服的，再多就会很难受，所以单体架构是比较适用于功能比较固定，变化不大一些传统项目。个人感觉，个人感觉微服务架构中最核心的就是HTTP资源API这样轻量的机制来相互通信。就是基于此基础上，各个技术都能采用统一的通信规范，那我就可以采用不同的技术开发各个微服务。还有我觉得微服务就很像jar包，以前是把用一套相关功能的代码封装成一个jar包，要用引入一下就可以了。现在是把一套相关功能的模块封装成一个微服务，要换不同的实现随时启动一下就可以了，感觉思想是一脉相承的。现在有了maven来管理各个jar包的依赖，随着一个系统中微服务的数量逐渐增长，他们相互依赖的复杂度增加，以后会不会也需要一些工具来管理他们之间的关系呢（不是指服务发现与注册）？还有我个人觉得比较需要注意的两点，一个是接口，一个是多技术。如果接口设计不好，随着开发时间的增长，接口改动的复杂度应该是越来越高，牵扯到的模块也会越来越多，乃至产生连锁反应？再说多技术，如果说只用一到套技术，那只要会一种技术的人员也是可以维护所有微服务的。但如果采用多种技术开发各个微服务，如果某个服务出了问题只能找相关的技术人员进行处理，以致公司每种技术的人员都要养着以备时刻维护各个微服务。所以我觉得虽然说允许采用不同的技术，但是还是应该采用一种技术作为主要开发手段，按需引入其它技术进行支持。