微服务的意义?

冒牌青年 发布于 09/17 17:41
阅读 1K+
收藏 0

          近期研究微服务架构在思考一个问题,就是通常情况下web系统的性能瓶颈都来自于数据库读写层面。那么是否我只做数据库的读写分离还有集群以及分库分表这样的处理,然后代码层面还是使用单体价格其实就可以解决大部分的问题?如果这样的话代码层面的微服务化设计的意义还在于哪里呢?

加载中
1
意简美
意简美

微服务可以让老板扩团队、加工资……

杨哥哥
杨哥哥
:+1:
1
码农小胖哥
码农小胖哥

大部分是拿来跟老板吹牛逼    让技术leader炫技   找工作的码农有底气

1
letwang
letwang

在大陆,喊微服务的,10个有9个是骗子。

嘴上喊着微服务,背地里行那苟且耦合之能事,leader在吹逼唬小弟,老板拿去忽悠客户,小弟门熬夜加班解BUG铁打的营盘流水的兵走了一波又一波,HR一直招人忙的不亦乐乎,一切都是欣欣向荣的样子,但是,当1000人或者100人并发读写时发现系统立马瘫痪了,一切回到原点~

当崩盘的那一刻,没有一片雪花是无辜的,留给企业的就是一地鸡毛,人力成本居高不下,资金链每天在走钢丝靠融资贷款抵押豪宅度日,技术还是10年前的技术,只不过概念和PPT的档次 上去了。

----来自 https://github.com/letwang/HookPHP

0
Windoze
Windoze

微服务架构是一种面向产品经理编程的方式。

如果贵司没有一天提28个需求的产品经理,那么对微服务的需求不会很强烈。

0
爱炒股的码农

车间流水线了解一下,微服务后更易于维护,量产和手工定制的区别

0
TonyJian
TonyJian

一个团队开发,不是大型聚合应用,没有很多的用户,就没啥必要了吧

0
小腊肠
小腊肠

微服务主要是解决人的问题, 模块化开发会更清晰, 甚至数据逻辑和业务逻辑是分开开发的,  对于运维来说, 应用的颗粒度更细了, 也有助于服务器的伸缩.

0
zhaobohao
zhaobohao

传统意义上的单体开发架构 ,在开发和运营方面存大着很多瓶颈。微服务的使用可以参考以下几点:

  • 微服务使用的前提,首先要有一个持续集成的平台
  • 其次在接入层,API 和 UI 要动静分离
  • 其三对于数据库,需要进行良好的设计,不应该有大量的联合查询
  • 其四要做应用的无状态化,只有无状态的应用,才能横向扩展

微服务相对于单体服务,在开发阶段可以解决以下问题:

  • 快速迭代
  • 提交代码频繁出现大量冲突
  • 小功能要积累到大版本才能上线,上线开总监级别大会
  • 高并发
  • 横向扩展流程复杂,主要业务和次要业务耦合
  • 熔断降级全靠 if-else

微服务的使用规范有以下几点:

  • 服务拆分最多三层,两次调用
  • 仅仅单向调用,严禁循环调用
  • 将串行调用改为并行调用,或者异步化
  • 接口应该实现幂等
  • 接口数据定义严禁内嵌,透传
  • 规范化工程名

套用敏捷开发里的一句话,能运行的程序胜过一切tmd文档和方法。

0
innerloop
innerloop

从需求角度,对于产品 模块多,既有标准化的功能,有需要满足客户个性化功能,数据隔离等,典型的SasS产品 就比较适合这种架构
从开发角度,对于大平台,模块多,尤其是存在多团队的共同开发的情况,可以做到隔离。
从产品角度,如果产品经理事多,胡思乱想,不负责任的提出或者答应需求,就可以单独弄一个服务来对付他,不靠谱的需求 都放里,能用就行,省着打嘴仗,又不影响核心业务

我们目前就没用这个,对于我们来讲架构太大了,modules和jar +docker 啥的 完全满足需求

0
k
kingMH

1、微服务架构和单体架构最大差别是同步和异步
2、微服务架构主要应用在平台级别的软件系统中,场景特点是用户多,并发高,业务复杂,迭代快,必然要异步化
3、单体架构无状态化后也能水平扩张,持续集成和容器化也不是不行

雷兽
。。。。我怎么觉得 服务化 和 单体架构就已经分开了呢 谈不上你说的1 异步与同步的区别 微服务说的不是服务化吧?
返回顶部
顶部