威哥也谈微服务

╰半橙微兮° 2022-05-16 05:22 243阅读 0赞

**威哥也谈微服务**

# **1、什么是微服务？** #

从字面意义上理解，我们可以这样拆分，“微”&“服务”。

“微”狭义来讲就是体积小，单一职责。

“服务”不是系统，服务是服务于一个或者一组相对较小的且独立的功能单元，可理解为：用户可以感知的最小功能集。

提微服务，就必须提Martin Fowler（马丁·福勒），这位软件界的大神于2014年提出微服务架构。

![70][]

马丁·福勒大致是这样描述服务：

**微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并且使用轻量级的Api****机制通讯，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务可使用不同的编程语言实现，以及不同的数据存储技术，并保持最低限度的集中式管理。**

可以总结概括为**4**点：

1.  **根据业务模块来划分服务种类；**
2.  **每个服务可以独立部署和互相隔离；**
3.  **通过    ** **轻量级API****调用服务；**
4.  **服务需要保证良好的高可用性；**

# **2、微服务功能架构图** #

![70 1][]

# **3、为什么要使用微服务？** #

![70 2][]

在传统的IT行业软件大多都是各种独立的单体系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE或者.Net。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。

一般公司在最早期，都是采用单体架构模式，因为公司早期的业务相对简单，单体模式更容易开发和凸显效果。但是后期随着公司规模的扩大，必然导致系统业务的不断延伸和业务复杂性不断增加，系统规模的扩大，必然会暴露单体模式的越来越多问题，总结大概如下：

*  **业务复杂性逐渐变高；**

单体模式后期代码堆积，各个业务模块高度耦合，牵一发而动全身。

*  **技术债务逐渐上升；**

公司员工离职流动，而他负责的代码模块疏于管理和代码备注，同时缺乏开发文档，导致留下很多坑给后来者，在单体模式高度耦合的情况下，这些坑还很难被发现，可能系统运行时某个业务场景就突然崩溃。

*  **部署速度逐渐变慢；**

单体模式后期越来越大，会导致部署花费时间越来越长，可能只是商品某个环节逻辑修改，但是整个应用都得一起发布。

*  **阻碍技术创新；**

单体模式都是统一的技术方案和编程语言实现，可能单独模式系统在开发之初，使用的最新的技术，可是后面自然而然的技术就会被落伍。比喻原来在WebForm下开发，现在要切换到MVC模式，这个工作量就相当庞大了，特别是语言切换上，更是不实际，整个系统相当于推到重新开发。

*  **无法按需伸缩；**

系统由于订单量暴增，针对订单模块，服务需求量暴增导致性能瓶颈，需要提升解决，可是在单体模式下面，本来只需要解决订单和商品模块的服务瓶颈，却被迫变成了提升所有服务的性能，所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。

企业软件发展的不同时期、阶段，对技术的理解，选择和应用都有着不一样的述求。架构的选型没有最好，只有最合适。单体模式在企业创业初期可能是最合适企业快速开发和发展的选型，而后期微服务可能更符合我们有业务复杂性的目标。软件演进的架构图可以大致归纳如下：

![70 3][]

# **4、如何理解微服务？** #

![70 4][]![70 5][]

1.  微服务，其关键不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级。同时系统架构上微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”可以总结如下：
    
    1.  统一风格的界面，
    2.  统一的权限管理，
    3.  统一的安全策略，
    4.  统一的上线过程，
    5.  统一的日志和审计方法，
    6.  统一的调度方式，
    7.  统一的访问入口。
2.  **微服务的目的是有效**的**拆分应用，实现敏捷开发和部署 ，**按照业务来拆分服务，在业务层面“水平拆分”系统；在技术层面前后分离，“垂直拆分”系统。纵横一起切，把单一的应用拆分为网状的小模块应用，体现微服务的本质：“微”**；**
3.  **微服务要能**独立部署与互相隔离，这是微服务中“服务”思想的体现，服务所属业务模块之间松耦合，互相边界隔离；
4.  微服务推荐通过轻量级的API（如restful，http服务+json数据如果是）互相通信；
5.  微服务提倡的理念团队间应该是：定义好系统的边界和接口，在一个团队内全栈，让团队自治，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此的依赖耦合能变弱，跨系统的沟通成本也就能降低；

# **5、微服务设计原则？** #

*  **单一职责原则**

*  意思是每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。

*  **服务自治原则**

*  意思是每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。

*  **轻量级通信原则**

*  首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。

*  **接口明确原则**

*  由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。

**综上所述，可以给出如下微服务的概念：**

![70 6][]

# **6、如何开始准备微服务？** #

可以从下面5方面来准备微服务：

*  业务拆分，体现在设计环节：在设计时，要有足够的判断力来合理的规划服务之间的界限。

*  服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。

*  自动测试，一定要自动化测试。微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。

*  自动运维： 微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。

*  监控：包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。![70 7][]

# **7、什么样的项目时候微服务？** #

上面说过，软件业没有最好，只有最合适。什么样的系统才适合使用微服务架构？主要取决于4个要素：

*  **小**：微服务体积小，2 pizza 团队；

*  **独**：能够独立的部署和运行；

*  **轻**：使用轻量级的通信机制和架构；

*  **松**：为服务之间是松耦合的；

# **8、微服务的优点？** #

*  **易于开发和维护**

*  由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。

*  **启动较快**

*  这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。

*  **局部修改容易部署**

*  在开发中发现了一个问题，如果是单体架构的话，我们就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug我们只需要解决那个模块的bug就可以了，解决完bug之后，我们只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。

*  **技术栈不受限**

*  比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。

*  **按需伸缩**

*  我们上面说了单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于我们微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。

# **9、微服务的缺点？** #

*  **运维要求较高**

*  对于单体架构来讲，我们只需要维护好这一个项目就可以了，但是对于微服务架构来讲，由于项目是由多个微服务构成的，每个模块出现问题都会造成整个项目运行出现异常，想要知道是哪个模块造成的问题往往是不容易的，因为我们无法一步一步通过debug的方式来跟踪，这就对运维人员提出了很高的要求。

*  **分布式的复杂性处理**

*  对于单体架构来讲，我们可以不使用分布式，但是对于微服务架构来说，分布式几乎是必会用的技术，由于分布式本身的复杂性，导致微服务架构也变得复杂起来。

*  **接口调整成本高**

*  比如，用户微服务是要被订单微服务和电影微服务所调用的，一旦用户微服务的接口发生大的变动，那么所有依赖它的微服务都要做相应的调整，由于微服务可能非常多，那么调整接口所造成的成本将会明显提高。

*  **重复劳动**

*  对于单体架构来讲，如果某段业务被多个模块所共同使用，我们便可以抽象成一个工具类，被所有模块直接调用，但是微服务却无法这样做，因为这个微服务的工具类是不能被其它微服务所直接调用的，从而我们便不得不在每个微服务上都建这么一个工具类，从而导致代码的重复。

[70]: /images/20220516/c587fbe3f25940508b981142faf328d6.png
[70 1]: /images/20220516/6f3de33c67ba4e90a028f688bd475611.png
[70 2]: /images/20220516/fefcb799ef1841888580adde283874c5.png
[70 3]: /images/20220516/2ec10119609b4179a591499a9ccaaf81.png
[70 4]: https://img-blog.csdn.net/20180816140507689?watermark/2/text/aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3h1d2VpX25ldA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70
[70 5]: /images/20220516/b7fa13e8b952412eac479e4e428915ca.png
[70 6]: /images/20220516/971691171097422182048f7cd84c0dbf.png
[70 7]: /images/20220516/3715d5a8f03943b7a1fb38f118e788d7.png