5
回答
搞微服务有什么意义
百度AI开发者大赛带你边学边开发,赢100万奖金,加群:418589053   

        到底系统的复杂性有多少才需要搞微服务。据说微服务是把系统按各种业务拆分成不同的系统。比如一个电商系统分成商品服务,订单服务等。不这样拆分就不能解决瓶颈,扩展,容错了吗?我把所有的服务写到一个应用里面,然后搞多个tomcat负载均衡,这样不是一样解决这些问题了吗?并且还避免了分布式事务的问题。

        微服务难道是技术控拿来折腾解乏的?

<无标签>
举报
喜之郎
发帖于1年前 5回/1K+阅
共有5个答案 最后回答: 1年前

Java厂商不折腾些新概念出来还怎么忽悠怎么卖解决方案?

微服务放到PHP里其实就是一个常见得不能再常见的页面控制器,不同页面控制器相互独立运行。

PHP之父早就对此有深刻的认识,批判过那些统一入口的前端控制器模式:
转载:
随着前端控制器使用的泛滥,越来越多人开始质疑PHP框架是否有必要使用前端控制器.这里以PHP之父Rasmus Lerdorf的影响最大,他在Simple is Hard里陈述了如果想开发出有扩展性的Web应用,必须保证架构是Share-nothing Architecture:
http://talks.php.net/show/ntu/
* Like HTTP, each request is distinct (像HTTP一样,每个请求都是独立的)
* Shared data is pushed down to the data-store layer (共享的数据应该放到存储层)
* Avoid Front Controller (不要使用前端控制器)

在Rasmus Lerdorf看来,想要让一个网站具有良好的扩展性其实是非常简单的, 只需将网站应用分成若干个独立小程序,前端透过API提供服务,后端是应用程序引擎,这样做自然会有扩展性. 因为应用的每一个部分,都有不同等级的使用方式,需要有不同的扩充程度,需要不同的机制来处理. 以开发雅虎电子邮件而言,是要开发一个地址服务程序,一个读信服务,一个送信服务,而送信程序完全和读信程序无关. 以雅虎的规模而言,需要让这些工作完全分离,才有扩充性. 这里的关键是你必须建立分离,模块化的独立端点,而不是全部放在同一个大篮子里. 大多数现今开发的框架,都使用了前端控制器,每一次浏览器发出请求时, 就会调用这个前端控制器,再由前端控制器来分辨,使用者想要执行哪一支程序.这样做,一点意义都没有. 在浏览器层面,程序完全能知道用户想要做什么事情,例如使用者只是要读信,程序就不用再把需求送到服务器,让服务器判断使用者要读信还是送信. 将这类决策工作拉出浏览器,由服务器处理,就会浪费大量服务器资源,来处理那些对用户没有实际作用的工作.
总结:
首先,前端控制器里存在一个路由转发的过程,这个过程是在服务端完成的, 不管是什么请求都要经由前端控制再完成路由转发,这个过程很可能会引起性能问题. 如果抛弃了前端控制器的做法,转而使用页面控制器的实现方式,那么服务端就不必再存在路由转发的过程, 因为在把页面渲染到浏览器上的时候,自然而然就完成了路由的设定,不同的动作对应着不同的URL. 功能实现则完全由页面控制器来实现.如果某个动作引起了性能的瓶颈,那么我们只要针对这个动作对应的URL增加更多的服务器就可以完成扩展. 另外,传统的MVC理论里,强调代码逻辑上的分离,但并未就物理分离做出描述,Rasmus Lerdorf在这方面做出了有益的补充. 按Rasmus Lerdorf的引申想法,M和V是分别位于不同服务器的,V通过WebService调用M上的数据. 请牢记Rasmus Lerdorf的教诲.

有人分析了Laravel这种使用前端控制器统一入口进行路由的PHP框架,其中路由分析占去了大量时间:

集群负载均衡整个项目只能横向扩展,纵向扩展还得用分布式,微服务独立出来又可以把这个微服务集群和负载均衡,理论上这个结构可以无限拓展。

我原来转载过一篇负载均衡的六大方式的文章,现在常用的负载均衡是用web服务器做反向代理的方式实现的,而反向代理服务器也是有性能瓶颈的。

像淘宝、亚马逊这种超大型电商系统,肯定不能用简单的集群和负载均衡实现的,他们中间都有很多个服务中间件,每个中间件其实就是一个微服务。

--- 共有 11 条评论 ---
喜之郎 回复 @公孙二狗 : 你这个问题问的好。这里nginx只是个例子。下面我就跟你讲讲如何解决这个单点nginx的瓶颈的方法。这个nginx接收到请求后把用户url重定向到后方的100台nginx的任意一台上。以后请求就一直跟后方的nginx打交道。也就是说,只有第一次请求会由前方的这个一个负载均衡处理,以后的请求根本不需要经过他,你说他的能有瓶颈吗? 1年前 回复
公孙二狗还有一个问题,例如数据库,就算你能挂上 1000 个 Tomcat 跑起来了,但是它们都要连到数据库上吧,每个 Tomcat 和数据库 100 个链接,MySQL 默认是 1024,你可以设置大一些,但也是有限的,就算数据库集群也很难搞定这里多服务器的,所以如果有这么多,甚至更多的服务器时,能够把数据访问的服务拆分出来做成不同的服务,才可以解决这个问题。 1年前 回复
公孙二狗 回复 @公孙二狗 : 就算一台 Nginx 上挂 100 个 Nginx,但是入口 Nginx 是单台,它的并发并没有解决。 1年前 回复
公孙二狗很简单,例如一台 Nginx 一般能够处理 4 万左右的并发,据说搞的好的能上 20 万,阿里,京东,腾讯,12306 这些,20 万并发毛毛雨都算不上,再好的上 F5 等,但单台机器总是能力有限,这个时候还真的集群是解决不了的。 1年前 回复
喜之郎回复 @BoXuan : 上千很多吗?Google的搜索节点恐怕不只上千。 1年前 回复

LZ的想法有点偏了,所有的服务写到一个应用里面,但并不是所有的服务都需要集群,本着资源用到刀刃上,给有需要的服务做集群,所有才有微服务。

大多数应用其实根本没到微服务级别,只不过大家都喜欢玩一下技术,而且这也算最前沿的技术,dubbo 、spring cloud、 zookeeper,包括消费列队,学一学也挺好的

--- 共有 2 条评论 ---
喜之郎是浪费了CPU,还是硬盘?如果订单服务比商品服务更耗CPU,把他们都放一台机器上或者拆开机器开耗的CPU一样。 1年前 回复
喜之郎不拆分服务浪费了什么资源, 1年前 回复

多tomcat集群是解决不了并发瓶颈的。web服务器集群只能解决容错。因为压力很少会在web服务器上,一般都是在CPU、IO、数据库上。你多tomcat集群,你数据库怎么保证可用,一个还是集群?你缓存怎么保证可用?这两个问题如果是多tomcat集群,非常难以解决,因为数据库的连接数是有限的;也正因为如此,所以才需要把tomcat的功能单一化,就页面渲染,当然也需要集群,以确保有容错能力;服务层抽出来单独处理,单独提出来之后,数据与缓存这块儿的问题就好解决了,压力分散,可以无限扩展。那服务层单独提出来之后,也需要一个规范化的标准,以便分布式,不就是微服务的概念的了么~

另外,分布式的微服务在发布时有非常大的优势,可以做灰度,只更新服务可以保证服务7*24小时,而且速度快非常多。对于开发的管理也很方便,可以快速敏捷迭代,你想想你开发的时候启动一个jar快,还是启动一个tomcat工程快?

--- 共有 5 条评论 ---
francis-x 回复 @喜之郎 : 我补充一点,你还是想想目前项目的痛点再决定是不是需要实施微服务吧。微服务不能包治百病,只是一种架构理念,空谈是没有用的。我们公司十几个项目,项目规模都不算大,但两年前就开始慢慢转向微服务了,因为他能解决我们的一些问题:效率低、发布慢、扩展困难、多个项目里重复服务不能共用、服务管理困难等问题。 1年前 回复
francis-x 回复 @喜之郎 : 看场景,看问题,1000个tomcat并不代表实时请求的就有那么多,这个需要具体问题具体分析。但是管理难度跟单tomcat容器有很大的区分,我可以对服务进行监控、管理,这个有现成的开源工具去支撑,无论是dubbo还是esb还是其它的。但是如果放在tomcat里,以我的经验来说无法快速准确的判断,只能通过日志啥的慢慢分析。 1年前 回复
francis-x 回复 @喜之郎 : 你不关心说明你的应用规模还不够大,调试、发布还没有遇到瓶颈。如果这种项目是短期工程,那你确实用不到微服务,按照喜欢的架构搞搞就好了。但是如果是长期项目,这种架构的项目发展个几年,规模会变大,可能同时开发测试需要几十人几百人进行协同。开发、部署、测试、集成的任意环节都是非常痛苦的。只有拆分服务,只有提高每个环节的效率才能提高产能。 1年前 回复
喜之郎启动速度就不要拿出来说了,根本不是我讨论的问题。要那么快干嘛?反正有热备的,你启动慢点也无所谓。 1年前 回复
喜之郎假设搞了微服务,商品服务已经有1000台tomcat了,假设此时商品数据库mysql提供不了这么多连接。如何解决? 1年前 回复
顶部