1、单体架构存在的问题
(1)复杂性高:项目包含的模块非常多、模块的边界模糊、依赖关系不清晰、代码质量参差不齐、混乱地堆砌在一起整个项目非常复杂.
(2)技术债务:随着时间推移、需求变更和人员更迭,会逐渐形成应用用程序的技术债务,并且越积越多。
(3)部署频率低:随着代码的增多,构建和部署的时间也会增加。而在单体应用中,每次功能的变更或缺陷的修复都会导致需要重新部署整个应用。
(4)可靠性差:某个应用Bug,例例如死循环、OOM等,可能会导致整个应用的崩溃。
(5)扩展能力受限:单体应用只能作为一个整体进行扩展,无法根据业务模块的需要进行伸缩。
(6)阻碍技术创新:单体应用往往使用统一的技术平台或方案解决所有的问题,团队中的每个成员都必须使用相同的开发语言和框架,要想弓引入新框架或新技术平台会非常困难。
2、什么是微服务
微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法,每个服务运行在自己的进程中,服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理,服务可用不同的语言开发,使用不同的数据存储技术。
特点：
(1)每个微服务独立运行在自己的进程中。
(2)系列独立运行的微服务共同构建起整个系统。
(3)每个服务为独立的业务开发,一个微服务只关注某个特定的功能,例如订单管理、用户管理等。
(4)微服务之间通过一些轻量的通信机制进行通信,例例如通过 RESTFUL API进行调用。
(5)可以使用不同的语言与数据存储技术。
(6)全自动的部署机制。
优点：
(1)易于开发和维护:一个微服务只会关注一个特定的业务功能,所以它业务清晰、代码量较少。开发和维护单个微服务相对简单。而整个应用是由若干个微服务构建而成的,所以整个应用也会被维持在一个可控状态。
(2)单个微服务启动较快:单个微服务代码量较少,所以启动会比较快。
(3)局部修改容易部署:单体应用只要有修改,就得重新部署整个应用,微服务解决了这样的问题。一般来说,对某个微服务进行修改,只需要重新部署这个服务即可。
(4)技术栈不受限:在微服务架构中,可以结合项目业务及团队的特点,合理地选择技术栈。例如某些服务可使用关系型数据库 MYSQL;某些微服务有图形计算的需求,可以使用Neo4j;甚至可根据需要,部分微服务使用Java开发,部分微服务使用 Node.js开发。
(5)按需伸缩:可根据据需求,实现细粒度的扩展。例如,系统中的某个微服务遇到了瓶颈,可以结台这个微服务的业务特点点,增加加内存、升级CPU或者是增加节点。
设计原则：
单一职责原则
指的是一个单元(类、方法或者服务等)只应关注整个系统功能中单独、有界限的一部分。单一职责原则可以帮助我们更优雅地开发、更敏捷地交付。单一职责原则是 SOLID原则之一。有兴趣的读者可前往htps∥en. wikipedia. org/wiki/
服务自治原则
服务自治是指每个微服务应具备独立的业务能力、依赖与运行环境。在微服务架构中,服务是独立的业务单元,应该与其他服务高度解耦。每个微服务从开发、测试、构建、部署,都应当可以独立运行,而不应该依赖其他的服务。
轻量级通信机制
微服务之间应该通过轻量级的通信机制进行交互。笔者认为,轻量级的通信机制应具备两点:首先是它的体量较轻;其次是它应该是跨语言、跨平台的。例如我们所熟悉的REST协议,就是一个典型的“轻量级通信机制”;而例如Java的RMI则协议就不大符合轻量级通信机制的要求,因为它绑定了Java语言。
微服务架构中,常用的协议有REST、AMQP、 STOMP、MQTT等。
微服务粒度
微服务的粒度是难点,也常常是争论的焦点。应当使用合理的粒度划分微服务,而
不是一味地把服务做小。代码量的多少不能作为微服务划分的依据,因为不同的微服务本身的业务复杂性不同,代码量也不同
