037 关于微服务的认识

Posted 2021-01-12 juncaoit

　　对于微服务，还是只是一个感性的理解，缺乏系统的整理。

　　而且，读每一篇文章，都感觉有道理。这样就需要，先将人家比较好的文档列举，然后整理出自己文档。

一：一个简单的普通的理解，不涉及具体的技术

　　一、什么是微服务？
　　微服务架构风格是一种讲一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，这些服务围绕业务能力构建并且可通过全自动部署机制独立部署，这些服务公用一个小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储。
　　微服务具备以下的特性：

　　　　每个微服务可独立运行在自己的进程里
　　　　一系列独立运行的微服务共同构建起整个系统
　　　　每个微服务为独立的业务开发，一个微服务只关注某个特定的功能
　　　　微服务之间通过一些轻量级的通信机制进行通信
　　　　可以使用不同的语言和数据存储技术
　　　　全自动部署机制
　　二、微服务的优点
　　　　易于维护和开发：一个微服务只关注一个特定的业务功能，所以它业务清晰，代码量较少，开发和维护单个微服务相对简单
　　　　单个微服务启动较快：单个微服务代码量少，所以启动较快
　　　　局部修改容易部署
　　　　技术栈不受限：在微服务架构中，可以结合项目业务及团队的特点合理的选择技术栈
　　　　按需伸缩：可根据需求实现细粒度的扩展
　　三、微服务面对的挑战
　　　　运维要求较高：更多的服务以为者更多的运维投入
　　　　分布式固有的复杂性：使用微服务构建的是分布式系统，对于一个分布式系统，系统容错，网络延迟，分布式事物都会带来巨大的挑战
　　　　接口调整成本高：微服务之间通过接口进行通信，如果修改某一个微服务的API，可能所有使用该接口的微服务都需要调整
　　　　重复劳动：很多微服务都会使用到相同的功能，而这个功能还没有达到分解为一个微服务的程度，这个时候，可能各个服务会开发这一个功能而导致代码重复
　　四、微服务设计的原则
　　　　单一职责原则：单一职责是指一个单元（类，方法或者服务等）只应关注整个系统功能中单独有界限的一部分
　　　　服务自治原则：服务自治原则是指每个微服务应具备独立的业务能力，依赖与运行环境
　　　　轻量级通信原则：微服务之间应该通过轻量级的通信机制进行交互
　　　　微服务粒度划分合理：微服务粒度是难点，应当使用合理的粒度划分微服务问不是一味的把服务做小，代码量的多少并不能作为微服务划分的依据，因为不同的微服务本身业务的复杂性不同，代码量也不同
　　---------------------
　　　　作者：zhao_double_huan
　　　　来源：CSDN
　　　　原文：https://blog.csdn.net/weixin_41098980/article/details/79826986?utm_source=copy
　　　　版权声明：本文为博主原创文章，转载请附上博文链接！

 

二：

1.微服务的由来

   　　微服务最早由Martin Fowler与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。

 

2.单体带来的问题

　　　　单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：

　　1.复杂性逐渐变高

• 比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。

　　2.技术债务逐渐上升

• 公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。

　　3.部署速度逐渐变慢

• 这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。

　　4.阻碍技术创新

• 比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。

　　5.无法按需伸缩

• 比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

 

3.微服务与单体的区别

1. 单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。

2. 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以使用不同的存储方式（比如有的用redis，有的用mysql等），数据库也是单个模块对应自己的数据库。

3. 单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发技术，开发模式更灵活。

 

4.微服务与SOA

　　微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python编写的服务，他们是靠Restful架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩展性强。

 

5.微服务的目的

　　微服务的目的是有效的拆分应用，实现敏捷开发和部署 。

 

6.什么样的项目适合使用微服务

 　　微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。

　　能不能做成微服务，取决于四个要素：

• 小：微服务体积小，2 pizza 团队。

• 独：能够独立的部署和运行。

• 轻：使用轻量级的通信机制和架构。

• 松：为服务之间是松耦合的。

 

7.微服务的拆分与设计