微服务开发的意义 微服务与分布式的关系
意义
将单体应用拆分为一组小服务,协同工作,小而自治,每个服务在独立的进程运行,服务之间使用轻量级的通信机制RPC。
单一职责,一个微服务解决一个业务问题,注意是一个业务问题而不是一个接口,服务围绕业务构建,服务可以独立部署,低耦合。
面向服务,将自己的业务能力封装并对外提供服务,一个微服务本身也可以有使用到其它微服务的能力,服务之间互不影响,复用性高,且有自动部署机制。
可以根据业务特殊性使用不同的编程语言和数据存储,实现异构型和去中心化。
易于开发,每个模块是一个服务,每个服务是一个项目,开发一个模块就只需要担心这个模块的逻辑即可,低耦合。
技术栈不受限,不同的微服务之间的编程语言编写,只需要关注逻辑即可,不需要关心实现过程,编程语言不限。
启动较快,相比于启动单体架构的整个项目,独立部署的微服务启动速度快。
修改容易,在开发中发现一个问题,如果是单体架构的话,需要重新发布并启动整个项目,耗时间。但是微服务开发,模块出现bug只需要解决模块的bug就可以了,解决完bug之后,重启模块的服务即可,不必重启整个项目,节约时间。
微服务与分布式
共同点:
将模块拆分成一个独立的服务单元通过接口来实现数据的交互。
为了不因为某个模块的升级和BUG影响现有的系统业务。
细微差别:
微服务是分布式架构,但微服务的应用不一定是分散在多个服务器上,可能是同一个服务器。
本作品采用《CC 协议》,转载必须注明作者和本文链接
上代码
不错
php ? 微服务?
java 有成熟方案,可以搭个java壳子里面服务具体在调用PHP
微服务这个概念已经很久了,但是很多人都没有真正的了解它。演进到今天,它无关乎语言,无关乎框架!
首先来说分布式吧,分布式可以是分布于多个主机,也可以是分布于多个集群,或者多个地理区域。主要是为了解决高可用问题,避免点一节点故障导致的服务不可用。分布式其实是从运维视角去解决问题!
微服务是从开发视角去解决单体项目过大,业务过于复杂而演变出来的一种架构,可以看作是上云的 1.0 。在这一阶段中,例如服务治理,流量追踪等实现,需要在项目的代码层实现。当然很多框架提供了 SDK,但这对于开发人员来说依然存在心智负担。
微服务架构演进的第二个阶段是 API Gateway 这类服务提供的 7 层流量转发能力。
第三个阶段是 SideCar,这种方式实现了将偏运维的逻辑从框架层抽象到了单独的服务中,开发者不用在业务代码中过度关注微服务的可靠性,这些都交给 SideCar 。
第四个阶段是 Service Mesh,也是目前正处于的一个阶段。它跟 SideCar 很像,但强于 SideCar 模式。
说了这么多,最后说一点:在实际生产环境中服务为了高可用,不可能不考虑单点故障仅部署在一个节点上。
99%的项目用不上微服务,除非你老板要求要一个人可以完成的活需要三个人来做