技术主管一直做微服务 程序员不干了

本文探讨了微服务架构的概念及其在企业中的应用。介绍了微服务架构的特点,包括服务间的轻量级通信、围绕具体业务构建、独立部署等。同时讨论了微服务的优势与挑战,以及在实际应用中应注意的问题。

  微服务的概念出现不是一天两天了,但是要追溯它的源头还要看SOA,毕竟微服务只是一种比较现代化的细粒度的SOA实现方式,并非从天而降突然出现的。但不得不承认,IT架构实现了从all in one到微服务架构转变,微服务架构模式(Microservice Architect Pattern)开始被越来越多的企业所接受。

  根据ThoughtWorks的首席科学家,马丁·福勒先生的定义:“微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务(途虎养车网的后台就是微服务),服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中服务与服务间采用轻量级的通信机制互相沟通(通常是基于HTTP协议的RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立的部署到生产环境、类生产环境等。另外,应当尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下文,选择合适的语言、工具对其进行构建。”

如何避免盲人摸象
如何避免盲人摸象

  比如某大型互联网公司的技术主管就深感微服务架构优势多多,比如复杂可控、灵活可扩展、独立部署、开发展对性强等等,当然最重要的还有降低TCO,毕竟在微服务架构模式下,当某一组件发生故障时,不会发现单块架构系统的进程内扩散等弊端故障会被隔离在单个服务中

  看起来好处多多,但是该部门程序员却表达了不满。因为在他们看来自己做了很多无用功。而且无论是分区的数据库架构还是对微服务架构的测试都有着极大的挑战。Nginx认为:“微服务”强调了服务大小,实际上,有一些开发者鼓吹建立稍微大一些的,10-100 LOC服务组。尽管小服务更乐于被采用,但是不要忘了这只是终端的选择而不是最终的目的。微服务的目的是有效的拆分应用,实现敏捷开发和部署

ohn Allspaw与Adrian Cockcroft争论微服务

ohn Allspaw与Adrian Cockcroft争论微服务

  由此可见,针对微服务这一热门话题,并没有绝对的好坏之分。笔者认为,企业在选择IT架构模式时应该根据自身需求来平衡,如果只需要建构一个简单的应用,那大可不必用微服务架构,单体式的架构可能更适合你;如果企业需要建构复杂应用,微服务架构化整为零的功能还是值得肯定的,但是在应用过程中微服务也有自身缺点,需要警惕。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值