2024年最全简述 Microservices(微服务)_microservices的简单实现(2),h5前端面试问题

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

原文同步至 http://waylau.com/ahout-microservices/


自 2014 年始,Microservices(微服务)一词越来越火爆,不谈 Microservices 彷佛就 out 了。那么什么是 Microservices?Microservices 架构与传统的架构有什么区别?何时应该采用 Microservices?如何构建 Microservices?

本文,就针对上述提到的问题,来简单介绍下 Microservices。

什么是 Microservices

微服务的诞生并非偶然: 领域驱动设计指导我们如何分析并模型化复杂的业务;敏捷方法论帮助我们消除浪费,快速反馈;持续交付促使我们构建更快、更可靠、更频繁的软件部署和交付能力;虚拟化和基础设施自动化(Infrastructure As Code)则帮助我们简化环境的创建、安装;DevOps 文化的流行以及特性团队的出现,使得小团队更加全功能化。这些都是推动微服务诞生的重要因素。

实际上,业界对于微服务本身并没有一个严格的定义。James Lewis 和 Martin Fowler 对 Microservices 架构做了如下定义:

简言之,Microservices 架构风格就像是把小的服务开发成单一应用的形式, 运行在其自己的进程中,并采用轻量级的机制进行通信(一般是 HTTP 资源 API)。这些服务都是围绕业务能力来构建,通过全自动部署工具来实现独立部署。这些服务,其可以使用不同的编程语言和不同的数据存储技术,并保持最小化集中管理。

Microservices 包含如下特征:

  • 组件以服务形式来提供:正如其名,微服务也是面向服务的。
  • 围绕业务功能进行组织:微服务更倾向于围绕业务功能对服务结构进行划分、拆解。这样的服务,是针对业务领域有着关完整实现的软件,它包含使用接口、持久存储、以及对旬的交互。因此团队应该是跨职能的,包含完整的开发技术:用户体验、数据库、以及项目管理。
  • 产品不是项目:传统的开发模式,是至力于提供一些被认为是完整的软件。一旦开发完成,软件将移交给维护或者实施部门,然后,开发组就可以解散掉了。而微服务要求开发团队对软件产品的整个生命周期负责。这要求开发者每天都关注软件产品的运行情况,并与用户联系的更紧密,同时承担一些售后支持。越小的服务粒度越容易促进用户与服务提供商之前的关系。Amazon 的理念就是“You build, you run it”,这也正是 DevOps 的文化理念。
  • 强化终端及弱化通道:微服务的应用致力松耦合和高内聚,它们更喜欢简单的REST 风格,而不是复杂的协议(如WS或者BPEL或者集中式框架)。或者采用轻量级消息总线(如 RabbitMQ 或 ZeroMQ 等)来发布消息。
  • 分散治理:这是跟传统的集中式管理很大区别的地方。微服务把整体式框架中的组件,拆分成不同的服务,在构建它们时将会有更多的选择。
  • 分散数据管理:当整体式的应用使用单一逻辑数据库对数据持久化时,企业通常选择在应用的范围内使用一个数据库。微服务让每个服务管理自己的数据库:无论是相同数据库的不同实例,或者是不同的数据库系统。
  • 基础设施自动化:云计算,特别是 AWS 的发展,减少了构建、发布、运维微服务的复杂性。微服务的团队更加依赖于基础设施的自动化,毕竟发布工作相当的无趣。近些年开始火爆的 Docker 也是一个不错的选择(可以参阅《简述 Docker》)。
  • 容错性设计:任务服务都可能因为供应商的不可靠而故障。微服务应为每个应用的服务及数据中心提供日常故障检测和恢复。
  • 改进设计:由于设计会不断更改,微服务所提供的服务应该能够替换或者报废,而不是要长久的发展的。

MSA vs. SOA

微服务架构(MSA)与 面向服务架构(SOA)相似之处,比如,都是面向服务。通常 SOA 意味着大而全的整体集中式的解决方案。这让设计、开发、测试、发布都增加了难度,其中任何细小的代码变更,都将导致整个系统的需要重新测试,部署。而微服务架构恰恰把所有服务都打散,设置合理的颗粒度,各个服务间保持低耦合,每个服务都在其完整的生命周期中存活,互相之间影响降到最低。

SOA 需要对整个系统进行规范,而 MSA 每个服务都可以有自己的开发语言、开发方式,灵活性大大提高。

何时采用 Microservices

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化的资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!**

  • 7
    点赞
  • 22
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
微服务架构中,服务之间需要进行相互调用,而OpenFeign可以作为一种服务调用的工具来实现这一过程。下面是OpenFeign实现服务调用的步骤: 1. 引入OpenFeign依赖 在项目的pom.xml文件中,引入OpenFeign依赖。例如: ``` <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-openfeign</artifactId> <version>2.2.2.RELEASE</version> </dependency> ``` 2. 创建Feign接口 在通过OpenFeign调用服务时,需要先创建一个Feign接口,用于定义服务调用的方法及其参数。例如: ``` @FeignClient(name = "service-provider", fallback = ServiceProviderFallback.class) public interface ServiceProviderFeignClient { @GetMapping("/hello") String hello(); @PostMapping("/user") User addUser(@RequestBody User user); @GetMapping("/user/{id}") User getUserById(@PathVariable("id") Long id); } ``` 其中,@FeignClient注解用于指定服务名,fallback属性用于指定服务降级处理类。 3. 调用Feign接口 在需要调用服务的地方,通过注入Feign接口的方式来调用服务。例如: ``` @RestController public class ConsumerController { @Autowired private ServiceProviderFeignClient serviceProviderFeignClient; @GetMapping("/hello") public String hello() { return serviceProviderFeignClient.hello(); } @PostMapping("/user") public User addUser(@RequestBody User user) { return serviceProviderFeignClient.addUser(user); } @GetMapping("/user/{id}") public User getUserById(@PathVariable("id") Long id) { return serviceProviderFeignClient.getUserById(id); } } ``` 通过调用Feign接口的方法,即可实现对服务的调用。 总体来说,OpenFeign是一种比较方便的服务调用工具,在微服务架构中得到了广泛的应用。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值