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

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

  •  
  •   MrMike · 150 天前 · 3846 次点击
    这是一个创建于 150 天前的主题,其中的信息可能已经有所发展或是发生改变。

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

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

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

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

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

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

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

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

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

    不如 现在的流程里加强 code review 什么的
        43
    MrMike   149 天前
    @WinterWu
    @yuhuan66666
    @nullen
    @lauix
    @feiyu1993
    @p2pCoder

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

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

    另外还有两个原因就是:

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

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

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

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

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