微服务开发的意义 微服务与分布式的关系

意义

将单体应用拆分为一组小服务,协同工作,小而自治,每个服务在独立的进程运行,服务之间使用轻量级的通信机制RPC。

单一职责,一个微服务解决一个业务问题,注意是一个业务问题而不是一个接口,服务围绕业务构建,服务可以独立部署,低耦合。

面向服务,将自己的业务能力封装并对外提供服务,一个微服务本身也可以有使用到其它微服务的能力,服务之间互不影响,复用性高,且有自动部署机制。

可以根据业务特殊性使用不同的编程语言和数据存储,实现异构型和去中心化。

易于开发,每个模块是一个服务,每个服务是一个项目,开发一个模块就只需要担心这个模块的逻辑即可,低耦合。

技术栈不受限,不同的微服务之间的编程语言编写,只需要关注逻辑即可,不需要关心实现过程,编程语言不限。

启动较快,相比于启动单体架构的整个项目,独立部署的微服务启动速度快。

修改容易,在开发中发现一个问题,如果是单体架构的话,需要重新发布并启动整个项目,耗时间。但是微服务开发,模块出现bug只需要解决模块的bug就可以了,解决完bug之后,重启模块的服务即可,不必重启整个项目,节约时间。

微服务与分布式

共同点:

将模块拆分成一个独立的服务单元通过接口来实现数据的交互。

为了不因为某个模块的升级和BUG影响现有的系统业务。

细微差别:

微服务是分布式架构,但微服务的应用不一定是分散在多个服务器上,可能是同一个服务器。

本作品采用《CC 协议》,转载必须注明作者和本文链接
《L01 基础入门》
我们将带你从零开发一个项目并部署到线上,本课程教授 Web 开发中专业、实用的技能,如 Git 工作流、Laravel Mix 前端工作流等。
《L02 从零构建论坛系统》
以构建论坛项目 LaraBBS 为线索,展开对 Laravel 框架的全面学习。应用程序架构思路贴近 Laravel 框架的设计哲学。
讨论数量: 9

上代码

1年前 评论

微服务这个概念已经很久了,但是很多人都没有真正的了解它。演进到今天,它无关乎语言,无关乎框架!

首先来说分布式吧,分布式可以是分布于多个主机,也可以是分布于多个集群,或者多个地理区域。主要是为了解决高可用问题,避免点一节点故障导致的服务不可用。分布式其实是从运维视角去解决问题!

微服务是从开发视角去解决单体项目过大,业务过于复杂而演变出来的一种架构,可以看作是上云的 1.0 。在这一阶段中,例如服务治理,流量追踪等实现,需要在项目的代码层实现。当然很多框架提供了 SDK,但这对于开发人员来说依然存在心智负担。

微服务架构演进的第二个阶段是 API Gateway 这类服务提供的 7 层流量转发能力。

第三个阶段是 SideCar,这种方式实现了将偏运维的逻辑从框架层抽象到了单独的服务中,开发者不用在业务代码中过度关注微服务的可靠性,这些都交给 SideCar 。

第四个阶段是 Service Mesh,也是目前正处于的一个阶段。它跟 SideCar 很像,但强于 SideCar 模式。

说了这么多,最后说一点:在实际生产环境中服务为了高可用,不可能不考虑单点故障仅部署在一个节点上。

1年前 评论
amateur (楼主) 1年前
自由与温暖是遥不可及的梦想

php ? 微服务?

1年前 评论
amateur (楼主) 1年前
自由与温暖是遥不可及的梦想 (作者) 1年前

java 有成熟方案,可以搭个java壳子里面服务具体在调用PHP

1年前 评论

99%的项目用不上微服务,除非你老板要求要一个人可以完成的活需要三个人来做

1年前 评论

讨论应以学习和精进为目的。请勿发布不友善或者负能量的内容,与人为善,比聪明更重要!