V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
MrMike
V2EX  ›  PHP

想使用微服务框架来构建项目,如何操作呢?

  •  
  •   MrMike · 2018-03-22 00:28:07 +08:00 · 6072 次点击
    这是一个创建于 1399 天前的主题,其中的信息可能已经有所发展或是发生改变。

    最近在考虑将项目拆分成一个个小模块,运行在 docker 里面,每个模块之间用 restful 的方式来通信,所以在考虑使用微服务的框架。

    目前的项目主要用 php 开发的,前两天了解了下 sprin cloud,看到一篇文章说是只能运行 java 的项目,所以就没继续了。

    对微服务了解不深,所以请问下有这方面经验的朋友,该如何选择呢?

    66 条回复    2018-03-24 06:34:53 +08:00
    1762628386
        1
    1762628386  
       2018-03-22 00:40:30 +08:00
    慢死吧
    1762628386
        2
    1762628386  
       2018-03-22 00:41:12 +08:00   ❤️ 1
    http 接口很慢的
    gdtv
        3
    gdtv  
       2018-03-22 00:44:56 +08:00
    @1762628386 可有解决办法或者更好的建议?
    Luckyray
        4
    Luckyray  
       2018-03-22 00:48:58 +08:00 via iPhone   ❤️ 1
    spring cloud 的好处是有很多现成的工具让你使用,你可以看看它包含了哪些组件,如果你的系统不是很复杂庞大的话,可能有些工具是用不到的,完全可以手动撸一套 PHP 简单版出来。

    微服务说白了就是拆分,但是可能本来业务就复杂,再拆一拆可能导致有几百个服务,成千上万个实例在跑,所以日志怎么收集,配置怎么统一更新,负载均衡怎么搞,服务提供方怎么找到服务使用方,需不需要熔断、升降级,一大票微服务的 api 怎么结合成统一的对外 api 等等。
    MrMike
        5
    MrMike  
    OP
       2018-03-22 00:49:13 +08:00
    @1762628386 那用什么快些?所有模块都放在一起?单一应用。
    MrMike
        6
    MrMike  
    OP
       2018-03-22 00:51:32 +08:00
    @Luckyray 恩。也考虑过自己撸,如果有现成的解决方案,更好,应该可以省点时间,也应该比我们自己撸考虑的更周全些。
    Luckyray
        7
    Luckyray  
       2018-03-22 00:54:34 +08:00 via iPhone
    @MrMike 这么一说的确没听过有现成的 PHP 框架……一提微服务就自动想 Java 了,不如换 Java ?😂
    Immortal
        8
    Immortal  
       2018-03-22 00:55:31 +08:00
    不知道楼主项目如何 之前也学习了很多关于微服务的知识 但是思前想后 自己手头项目还是没必要上微服务
    还是老话 在考虑怎么用之前,还是先想想想是否真的需要 除了说出去比较时髦 还得考虑之后的维护成本 就像 4l Luckyray 说的 上了微服务 就得考虑很多东西了 如果对于项目帮助不是很大 真不如不上
    MrMike
        9
    MrMike  
    OP
       2018-03-22 00:56:07 +08:00
    @Luckyray java。。哈哈,没精力也没时间去撸它了。
    orangeade
        10
    orangeade  
       2018-03-22 00:58:02 +08:00
    可以考虑 RPC 通信或者消息队列啥的,微服务之间全用 HTTP+Restful 也没必要吧
    orangeade
        11
    orangeade  
       2018-03-22 00:58:47 +08:00
    微服务有个好处就是解放语言选择的,不同微服务可以用不同的编程语言
    Immortal
        12
    Immortal  
       2018-03-22 00:59:10 +08:00   ❤️ 1
    而且个人觉得 http 没有想象中的慢 服务之间调用 前期用 http 完全没问题的
    MrMike
        13
    MrMike  
    OP
       2018-03-22 01:00:32 +08:00
    @Immortal 只因为目前手上项目的原因想拆分,所以就想到了用微服务。现在的项目里面,也分了很多模块,每个模块之间的关联性很强,有时候修改一个 bug 可能会带出其他的问题,当然也跟程序员的技术水平有关系。所以想把各个模块独立出来,形成一个独立的应用,这样的话,模块出问题了,不至于影响整个项目的运行。
    Immortal
        14
    Immortal  
       2018-03-22 01:05:38 +08:00
    @MrMike
    从你的描述来看 感觉不是微服务不微服务的问题 是业务逻辑拆分不够干净
    光讨论微服务 因为我自己也写 php 和 golang,微服务这块看的一直是 golang 方面的,php 我用 yaf 最多,通讯我一下子说的话就知道 yar 和 hprosed
    MrMike
        15
    MrMike  
    OP
       2018-03-22 01:05:46 +08:00
    @orangeade 各个应用之间如何通信,这个没决定,RPC 和 RESTFULL 比较,RESTFULL 要熟悉些。目前比较迷茫使用哪些软件来搭建项目框架。zookeeper 用来注册和发现,docker 用来运行各个模块,目前是这样考虑的,因为不了解 zookeeper,所以担心研究了半天,最后像了解 spring cloud 一样,只适合 java 的项目就浪费时间了。
    Immortal
        16
    Immortal  
       2018-03-22 01:07:18 +08:00
    @MrMike 光服务发现 除了 zookeeper 还有 etcd 和 consul
    MrMike
        17
    MrMike  
    OP
       2018-03-22 01:10:47 +08:00
    @Immortal 业务逻辑上是有点问题,项目的基础架构已经确定了,也开发了一段时间了,需求变化了,所以有时候为了赶时间,就没有那么严谨,导致现在业务逻辑比较乱,要是想去理顺,可能要花很多时间,所以就考虑把每一个模块拆分出来,然后逐步重构每一个模块,这样也不至于影响整个项目的运行了。
    MrMike
        18
    MrMike  
    OP
       2018-03-22 01:11:32 +08:00
    @Immortal 恩,在网上查的 zookeeper 推荐的比较多些。
    artandlol
        19
    artandlol  
       2018-03-22 07:14:44 +08:00 via iPhone
    回复都是 etcd 这么底层的? 当然是 Fabric8,集成 k8s 和 Jenkins 的一个框架
    sagaxu
        20
    sagaxu  
       2018-03-22 07:41:04 +08:00 via Android
    @1762628386 手上有个日均 5 亿次调用的 http 接口,单就协议开销而言,单机 100 亿次调用也吃得消,http 性能是比不过二进制协议,也不至于慢死吧。
    @MrMike 可以看看 swoole 和 swoole 之上的一些方案
    yuanfnadi
        21
    yuanfnadi  
       2018-03-22 08:02:06 +08:00 via iPhone
    k8s 可以解决你的任何问题。
    p2pCoder
        22
    p2pCoder  
       2018-03-22 08:22:51 +08:00 via Android
    服务注册与发现中心推荐 consul
    helloworld12
        23
    helloworld12  
       2018-03-22 09:03:51 +08:00
    @sagaxu 你服务器配置是怎样的?
    WinMain
        24
    WinMain  
       2018-03-22 09:04:34 +08:00
    spring cloud ? Dubbo ? 这两个用的最多吧,再加上一个 docker 的管理框架。
    我们公司用的 spring cloud,感觉很好上手。
    feiyu1993
        25
    feiyu1993  
       2018-03-22 09:09:58 +08:00
    基于 swoole 的 php-msf 微服务框架考虑下。
    p2pCoder
        26
    p2pCoder  
       2018-03-22 09:12:01 +08:00
    如果你要纯用 php 做微服务,包括 服务注册与发现,断路器 路由 网关 消息总线 配置置中心等所有功能,应该是很有挑战的
    我现在大数据部门用 python 做数据模型 部署和一些实时爬取的服务,都是用 python 完成注册到 eureka 或者 consul,然后其他用 spring cloud 实现其他功能
    WinterWu
        27
    WinterWu  
       2018-03-22 09:17:18 +08:00
    主要还是看业务本身,如果业务模型比较单一,用户容易区分,可以直接根据用户垂直切分,业务本身只需要根据需要简单扩容,这样只要在反代或者 LBS 上进行配置好规则,就很容易做到横行扩容。
    yuhuan66666
        28
    yuhuan66666  
       2018-03-22 09:28:19 +08:00
    @1762628386 #2 有多慢,你扔下一句话就跑了有慢的例子么 到多少并发时候会出现瓶颈
    yuhuan66666
        29
    yuhuan66666  
       2018-03-22 09:31:17 +08:00
    @WinMain #24 请问 你们注册中心用的是 eureka 还是 consul ? 有出现性能瓶颈吗?
    eccstartup
        30
    eccstartup  
       2018-03-22 09:31:40 +08:00 via iPhone
    @yuhuan66666 嗯,已屏蔽这种不负责任的回答
    yuhuan66666
        31
    yuhuan66666  
       2018-03-22 09:32:35 +08:00
    @p2pCoder #22 请问推荐理由是啥? eureka 呢?
    p2pCoder
        32
    p2pCoder  
       2018-03-22 09:38:15 +08:00
    @yuhuan66666 eureka consul 都可以,相比 zk 可用性和恢复能力都更好
    jowuIM
        33
    jowuIM  
       2018-03-22 09:41:39 +08:00
    为什么一定要微服务,真的需要吗?
    jyf
        34
    jyf  
       2018-03-22 09:46:41 +08:00
    其实我觉得这些技术选择倒不是重要的 重要的是如何拆接口到不同的服务去
    yuhuan66666
        35
    yuhuan66666  
       2018-03-22 10:00:50 +08:00
    @p2pCoder #32 感谢
    lauix
        36
    lauix  
       2018-03-22 10:24:10 +08:00
    可以考虑 RPC
    nullen
        37
    nullen  
       2018-03-22 10:43:26 +08:00   ❤️ 1
    微服务是业务逻辑的重新划分、切分,每个服务负责单一功能(职责),前台业务 拼装后端服务 实现业务逻辑。

    对比单体应用,往往是某个类来实现单一职责,前台业务代码通过调用类的方式来实现业务逻辑。
    服务化的应用,“类” 就变成一个个的服务,前台业务代码调用后端服务实现业务逻辑,服务之间的通讯方式目前大部分为 RPC。

    RPC 协议有很多,可以根据实际情况选择:
    1、比如基于 HTTP 协议的 JSON-RPC 也没那么“慢”;
    2、看业务要求,性能要求高的地方换 二进制协议的 RPC ( thrift,dubbo,gRPC ),效率更好。根据自己团队的技术情况选择;
    3、业界 Java 技术体系的轮子比较多。就我自己而言,我比较喜欢 gRPC。

    服务化会带来新的问题:问题排查、各种服务监控会变复杂。
    WinMain
        38
    WinMain  
       2018-03-22 10:46:38 +08:00   ❤️ 1
    @yuhuan66666 你的用户场景是?我们 app 日活不到千万,完全没问题。在没有碰到性能问题的时候,就不用考虑性能问题了,考虑 spring cloud 这个框架有多少大公司在用就可以了。
    MrMike
        39
    MrMike  
    OP
       2018-03-22 10:50:46 +08:00
    @WinMain spring cloud 只能运行 java 的项目吧,支持其他语言的么?
    MrMike
        40
    MrMike  
    OP
       2018-03-22 10:55:52 +08:00
    @p2pCoder 不是用 PHP 做纯的微服务,前几天一直在网上查,一查微服务,基本都是 spring cloud or zookeeper,后来还尝试安装了下 spring cloud,但是看到一篇文章说 spring cloud 只支持 java 的程序,我就不敢继续尝试下去了,因为时间消耗不起。
    p2pCoder
        41
    p2pCoder  
       2018-03-22 11:00:37 +08:00
    @MrMike 首先了解服务注册发现与健康检测,这个和语言没有关系,zk eureka consul 都可以,eureka consul 都是 http restapi 接口完成相应功能的,和语言无关
    hlwjia
        42
    hlwjia  
       2018-03-22 11:07:15 +08:00
    微服务做起来比说起来难多了,实际操作起来绝对比 monolithic 难多了,我说的还不是技术方面的难

    而且大多数公司的业务都用不着微服务,用了反而麻烦;对每个工程师要求也更高,要不是技术牛逼的团队,只会越搞越糟

    不如 现在的流程里加强 code review 什么的
    MrMike
        43
    MrMike  
    OP
       2018-03-22 11:10:02 +08:00
    @WinterWu
    @yuhuan66666
    @nullen
    @lauix
    @feiyu1993
    @p2pCoder

    感谢各位朋友的推荐。看到大家说了这么多,我都有点迷茫,是否真的需要使用微服务了,或许是我的帖子内容没说清楚。

    我的初衷其实很简单,就想把现在单一的应用里面很多模块拆分出来,形成一个独立的模块应用,然后模块之间采用一种合适的通信方式进行数据的交互,模块我是打算用 docker 来封装,每一个模块应该都有独立的数据库,这样的话,就算单独运行某一个模块,也都可以使用的。

    另外还有两个原因就是:

    1,团队的技术水平不一样,但是项目进度又摆在那里,有时间上的要求,不想一个新的开发人员为了开发一个小功能,去花时间学习新的框架,如果能用他们熟悉的框架或方式来实现,这样可以节省时间,然后再逐渐完善。
    2,现在的单一系统,修改一个问题,可能会涉及到很多模块的应用,数据库之间的关联性又特别强,有时候修改完后,测试员不够的情况下,没检查仔细,部署上去,就出问题了。
    abcbuzhiming
        44
    abcbuzhiming  
       2018-03-22 11:10:49 +08:00
    微服务不是银弹,微服务的本质是业务拆分和接口治理,特别是业务拆分,拆不好就完蛋,对于中小型项目,微服务其实付出了额外的代价
    abcbuzhiming
        45
    abcbuzhiming  
       2018-03-22 11:14:30 +08:00
    @MrMike 之前有篇文章说过一句话:微服务首先是组织架构,然后才是技术架构,它不是“团队技术不行时的选择”,它对整个团队的水平要求其实是提高了而不是降低了。
    单一应用的规模如果不够大的话用微服务其实没有优势
    微服务对测试和部署的要求其实更高
    micean
        46
    micean  
       2018-03-22 11:28:20 +08:00
    @MrMike
    1 如果开发时用五花八门的框架,以后人员离职维护工作怎么办?
    2 不如做好单元测试
    nullen
        47
    nullen  
       2018-03-22 11:30:56 +08:00
    @abcbuzhiming 赞同。
    WinMain
        48
    WinMain  
       2018-03-22 11:32:06 +08:00
    @MrMike 不知道有没有公司自己改的,也不太清楚官方有没有提供这种小办法供其他语言。暂时都是用 spring boot。
    wqqdhero
        49
    wqqdhero  
       2018-03-22 11:32:30 +08:00
    建议用 RPC 通信
    服务治理和部署很难搞
    如果是中小型 不太推荐 没啥必要 要付出很多额外代价
    myyou
        50
    myyou  
       2018-03-22 11:58:39 +08:00
    @nullen gRPC 也是基于 http 的只不过是 http2
    feverzsj
        51
    feverzsj  
       2018-03-22 12:06:30 +08:00
    微服务只适用于超大规模电商场景,其他 99.9%的业务场景都不适合
    tairan2006
        52
    tairan2006  
       2018-03-22 12:33:30 +08:00
    微服务只适用于大规模系统。

    微服务会带来很多问题,比如分布式事务、CQRS 啥的,一个人能写的项目用微服务是作死。
    akira
        53
    akira  
       2018-03-22 12:58:25 +08:00
    @MrMike 那结论很简单,微服务并不适合你。
    nullen
        54
    nullen  
       2018-03-22 13:06:02 +08:00
    @myyou 嗯,HTTP2 和 HTTP1 差别蛮大的。
    包括前几天 Nginx 开始支持 gRPC,我觉得 gRPC 在实际中的应用案例会越来越多。
    MrMike
        55
    MrMike  
    OP
       2018-03-22 13:09:35 +08:00
    @nullen
    @akira
    @tairan2006
    @wqqdhero

    好的,谢了各位。结贴了。
    amon
        56
    amon  
       2018-03-22 14:56:52 +08:00
    上面很多都对微服务妖魔化了。
    我个人觉得微服务对于中小项目也挺适合。
    系统架构:单机 -> 集群 -> 微服务

    一开始不一定要迈那么大步子,比如能将现有的单机架构的项目拆分为多个业务逻辑解耦的子项目。
    wellsc
        57
    wellsc  
       2018-03-22 14:59:46 +08:00
    架构 != 框架
    tanszhe
        58
    tanszhe  
       2018-03-22 15:12:24 +08:00
    把问题复杂了,大方向朝着简单化发展就行。在一个项目觉得太复杂了 可以把独立性强的拆出来通过 http 接口来调用。当拆出来的模块比较多了之后 而且 运行每个服务的机器也比较多了 就需哟搞个注册中心 来统一管理各个模块了 一步步慢慢来,这些方案成熟的很,什么语言都无所谓 原理都一样
    csl1995
        59
    csl1995  
       2018-03-22 15:36:38 +08:00
    将现有的系统微服务化的话,成本太高,如果系统不大不复杂还行,如果系统庞大那难度真的很大,不亚于将整个系统重构。如果这种情况的话建议还是多考虑下吧。
    如果新开始一个系统确实可以考虑使用微服务,不同的模块使用不同的技术栈,后期的维护升级也相对于要简单(招对应技术栈的人即可)。
    RainFinder
        60
    RainFinder  
       2018-03-22 15:44:38 +08:00
    说 http 慢的,你们还停留在 1.1 ?再说 restful 本就是为 http 设计的
    q397064399
        61
    q397064399  
       2018-03-22 15:48:58 +08:00
    @amon #56
    妖魔化? 老铁,服务之间的调用 通信,需要解决的问题多的很,这些在单体服务中不存在的问题
    不是上面一堆人说的一个 restful 请求就能描述清楚的
    est
        62
    est  
       2018-03-22 16:13:43 +08:00
    一般说微服务就是 rpc 没的跑。基本等价于 grpc。
    qdcanyun
        63
    qdcanyun  
       2018-03-22 16:30:35 +08:00
    微服务,调用链分析,服务发现,限流,熔断,负载均衡了解下。
    先尝试解耦你的 monolith 项目,如果 monolith 里的各个模块做不好单一职责,微服务照样也设计不好单一职责。
    先搞定单一职责,然后根据业务分组部署,快速部署,然后垂直拆分,最后再考虑服务化。

    「团队的技术水平不一样」问题,靠修订招人标准来解决,小团队除非是大牛,否则尽量招技术栈接近的人然后在一个技术栈上快速跑起来
    「现在的单一系统,修改一个问题,可能会涉及到很多模块的应用,数据库之间的关联性又特别强,有时候修改完后,测试员不够的情况下,没检查仔细,部署上去,就出问题了。」
    单一职责解耦,Code Review,自己写测试,灰度发布,蓝绿部署,多靠可具体执行的系统方案来解决问题,不要依靠人来解决稳定性。(测试员是什么鬼。。。。
    MrMike
        64
    MrMike  
    OP
       2018-03-22 17:28:01 +08:00
    @qdcanyun 非常感谢。
    cenphoenix
        65
    cenphoenix  
       2018-03-22 21:13:15 +08:00
    怎么现在貌似动不动就说要上微服务,真有那么大的访问量用得上微服务吗。
    rim99
        66
    rim99  
       2018-03-24 06:34:53 +08:00 via iPhone
    @MrMike protobuf 可以考虑一下
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   4251 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 31ms · UTC 02:02 · PVG 10:02 · LAX 18:02 · JFK 21:02
    ♥ Do have faith in what you're doing.