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

慢死吧

http 接口很慢的

@1762628386 可有解决办法或者更好的建议？

spring cloud 的好处是有很多现成的工具让你使用，你可以看看它包含了哪些组件，如果你的系统不是很复杂庞大的话，可能有些工具是用不到的，完全可以手动撸一套 PHP 简单版出来。

微服务说白了就是拆分，但是可能本来业务就复杂，再拆一拆可能导致有几百个服务，成千上万个实例在跑，所以日志怎么收集，配置怎么统一更新，负载均衡怎么搞，服务提供方怎么找到服务使用方，需不需要熔断、升降级，一大票微服务的 api 怎么结合成统一的对外 api 等等。

@1762628386 那用什么快些？所有模块都放在一起？单一应用。

@Luckyray 恩。也考虑过自己撸，如果有现成的解决方案，更好，应该可以省点时间，也应该比我们自己撸考虑的更周全些。

@MrMike 这么一说的确没听过有现成的 PHP 框架……一提微服务就自动想 Java 了，不如换 Java ？

不知道楼主项目如何 之前也学习了很多关于微服务的知识 但是思前想后 自己手头项目还是没必要上微服务
还是老话 在考虑怎么用之前,还是先想想想是否真的需要 除了说出去比较时髦 还得考虑之后的维护成本 就像 4l Luckyray 说的 上了微服务 就得考虑很多东西了 如果对于项目帮助不是很大 真不如不上

@Luckyray java。。哈哈，没精力也没时间去撸它了。

可以考虑 RPC 通信或者消息队列啥的，微服务之间全用 HTTP+Restful 也没必要吧

微服务有个好处就是解放语言选择的，不同微服务可以用不同的编程语言

而且个人觉得 http 没有想象中的慢 服务之间调用 前期用 http 完全没问题的

@Immortal 只因为目前手上项目的原因想拆分，所以就想到了用微服务。现在的项目里面，也分了很多模块，每个模块之间的关联性很强，有时候修改一个 bug 可能会带出其他的问题，当然也跟程序员的技术水平有关系。所以想把各个模块独立出来，形成一个独立的应用，这样的话，模块出问题了，不至于影响整个项目的运行。

@MrMike
从你的描述来看 感觉不是微服务不微服务的问题 是业务逻辑拆分不够干净
光讨论微服务 因为我自己也写 php 和 golang,微服务这块看的一直是 golang 方面的,php 我用 yaf 最多,通讯我一下子说的话就知道 yar和 hprosed

@orangeade 各个应用之间如何通信，这个没决定，RPC 和 RESTFULL 比较，RESTFULL 要熟悉些。目前比较迷茫使用哪些软件来搭建项目框架。zookeeper 用来注册和发现，docker 用来运行各个模块，目前是这样考虑的，因为不了解 zookeeper，所以担心研究了半天，最后像了解 spring cloud 一样，只适合 java 的项目就浪费时间了。

@MrMike 光服务发现 除了 zookeeper 还有 etcd 和 consul

@Immortal 业务逻辑上是有点问题，项目的基础架构已经确定了，也开发了一段时间了，需求变化了，所以有时候为了赶时间，就没有那么严谨，导致现在业务逻辑比较乱，要是想去理顺，可能要花很多时间，所以就考虑把每一个模块拆分出来，然后逐步重构每一个模块，这样也不至于影响整个项目的运行了。

@Immortal 恩，在网上查的 zookeeper 推荐的比较多些。

回复都是 etcd 这么底层的？ 当然是 Fabric8，集成 k8s 和 Jenkins 的一个框架

@1762628386 手上有个日均 5 亿次调用的 http 接口，单就协议开销而言，单机 100 亿次调用也吃得消，http 性能是比不过二进制协议，也不至于慢死吧。
@MrMike 可以看看 swoole 和 swoole 之上的一些方案

k8s 可以解决你的任何问题。

服务注册与发现中心推荐 consul

@sagaxu 你服务器配置是怎样的？

spring cloud ? Dubbo ? 这两个用的最多吧，再加上一个 docker 的管理框架。
我们公司用的 spring cloud，感觉很好上手。

基于 swoole 的 php-msf 微服务框架考虑下。

如果你要纯用 php 做微服务，包括 服务注册与发现，断路器 路由 网关 消息总线 配置置中心等所有功能，应该是很有挑战的
我现在大数据部门用 python 做数据模型 部署和一些实时爬取的服务，都是用 python 完成注册到 eureka 或者 consul，然后其他用 spring cloud 实现其他功能

主要还是看业务本身，如果业务模型比较单一，用户容易区分，可以直接根据用户垂直切分，业务本身只需要根据需要简单扩容，这样只要在反代或者 LBS 上进行配置好规则，就很容易做到横行扩容。

@1762628386 #2 有多慢，你扔下一句话就跑了有慢的例子么 到多少并发时候会出现瓶颈

@WinMain #24 请问 你们注册中心用的是 eureka 还是 consul ？ 有出现性能瓶颈吗？

@yuhuan66666 嗯，已屏蔽这种不负责任的回答

@p2pCoder #22 请问推荐理由是啥？ eureka 呢？

@yuhuan66666 eureka consul 都可以，相比 zk 可用性和恢复能力都更好

为什么一定要微服务，真的需要吗？

其实我觉得这些技术选择倒不是重要的 重要的是如何拆接口到不同的服务去

@p2pCoder #32 感谢

可以考虑 RPC

微服务是业务逻辑的重新划分、切分，每个服务负责单一功能（职责），前台业务 拼装后端服务 实现业务逻辑。

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

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

服务化会带来新的问题：问题排查、各种服务监控会变复杂。

@yuhuan66666 你的用户场景是？我们 app 日活不到千万，完全没问题。在没有碰到性能问题的时候，就不用考虑性能问题了，考虑 spring cloud 这个框架有多少大公司在用就可以了。

@WinMain spring cloud 只能运行 java 的项目吧，支持其他语言的么？

@p2pCoder 不是用 PHP 做纯的微服务，前几天一直在网上查，一查微服务，基本都是 spring cloud or zookeeper，后来还尝试安装了下 spring cloud，但是看到一篇文章说 spring cloud 只支持 java 的程序，我就不敢继续尝试下去了，因为时间消耗不起。

@MrMike 首先了解服务注册发现与健康检测，这个和语言没有关系，zk eureka consul 都可以，eureka consul 都是 http restapi 接口完成相应功能的，和语言无关

微服务做起来比说起来难多了，实际操作起来绝对比 monolithic 难多了，我说的还不是技术方面的难

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

不如 现在的流程里加强 code review 什么的

@WinterWu
@yuhuan66666
@nullen
@lauix/a>
@feiyu1993
@p2pCoder

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

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

另外还有两个原因就是：

1，团队的技术水平不一样，但是项目进度又摆在那里，有时间上的要求，不想一个新的开发人员为了开发一个小功能，去花时间学习新的框架，如果能用他们熟悉的框架或方式来实现，这样可以节省时间，然后再逐渐完善。
2，现在的单一系统，修改一个问题，可能会涉及到很多模块的应用，数据库之间的关联性又特别强，有时候修改完后，测试员不够的情况下，没检查仔细，部署上去，就出问题了。

微服务不是银弹，微服务的本质是业务拆分和接口治理，特别是业务拆分，拆不好就完蛋，对于中小型项目，微服务其实付出了额外的代价

@MrMike 之前有篇文章说过一句话：微服务首先是组织架构，然后才是技术架构，它不是“团队技术不行时的选择”，它对整个团队的水平要求其实是提高了而不是降低了。
单一应用的规模如果不够大的话用微服务其实没有优势
微服务对测试和部署的要求其实更高

@MrMike
1 如果开发时用五花八门的框架，以后人员离职维护工作怎么办？
2 不如做好单元测试

@abcbuzhiming 赞同。

@MrMike 不知道有没有公司自己改的，也不太清楚官方有没有提供这种小办法供其他语言。暂时都是用 spring boot。

建议用 RPC 通信
服务治理和部署很难搞
如果是中小型 不太推荐 没啥必要 要付出很多额外代价

@nullen gRPC 也是基于 http 的只不过是 http2

微服务只适用于超大规模电商场景，其他 99.9%的业务场景都不适合

微服务只适用于大规模系统。

微服务会带来很多问题，比如分布式事务、CQRS 啥的，一个人能写的项目用微服务是作死。

@MrMike 那结论很简单，微服务并不适合你。

@myyou 嗯，HTTP2 和 HTTP1 差别蛮大的。
包括前几天 Nginx 开始支持 gRPC，我觉得 gRPC 在实际中的应用案例会越来越多。

@nullen
@akira
@tairan2006
@wqqdhero

好的，谢了各位。结贴了。

上面很多都对微服务妖魔化了。
我个人觉得微服务对于中小项目也挺适合。
系统架构：单机 -> 集群 -> 微服务

一开始不一定要迈那么大步子，比如能将现有的单机架构的项目拆分为多个业务逻辑解耦的子项目。

架构 != 框架

把问题复杂了，大方向朝着简单化发展就行。在一个项目觉得太复杂了 可以把独立性强的拆出来通过 http 接口来调用。当拆出来的模块比较多了之后 而且 运行每个服务的机器也比较多了 就需哟搞个注册中心 来统一管理各个模块了 一步步慢慢来，这些方案成熟的很，什么语言都无所谓 原理都一样

将现有的系统微服务化的话，成本太高，如果系统不大不复杂还行，如果系统庞大那难度真的很大，不亚于将整个系统重构。如果这种情况的话建议还是多考虑下吧。
如果新开始一个系统确实可以考虑使用微服务，不同的模块使用不同的技术栈，后期的维护升级也相对于要简单(招对应技术栈的人即可)。

说 http 慢的，你们还停留在 1.1 ？再说 restful 本就是为 http 设计的

@amon #56
妖魔化？ 老铁，服务之间的调用 通信，需要解决的问题多的很，这些在单体服务中不存在的问题
不是上面一堆人说的一个 restful 请求就能描述清楚的

一般说微服务就是 rpc 没的跑。基本等价于 grpc。

微服务，调用链分析，服务发现，限流，熔断，负载均衡了解下。
先尝试解耦你的 monolith 项目，如果 monolith 里的各个模块做不好单一职责，微服务照样也设计不好单一职责。
先搞定单一职责，然后根据业务分组部署，快速部署，然后垂直拆分，最后再考虑服务化。

「团队的技术水平不一样」问题，靠修订招人标准来解决，小团队除非是大牛，否则尽量招技术栈接近的人然后在一个技术栈上快速跑起来
「现在的单一系统，修改一个问题，可能会涉及到很多模块的应用，数据库之间的关联性又特别强，有时候修改完后，测试员不够的情况下，没检查仔细，部署上去，就出问题了。」
单一职责解耦，Code Review，自己写测试，灰度发布，蓝绿部署，多靠可具体执行的系统方案来解决问题，不要依靠人来解决稳定性。（测试员是什么鬼。。。。

@qdcanyun 非常感谢。

怎么现在貌似动不动就说要上微服务，真有那么大的访问量用得上微服务吗。

@MrMike protobuf 可以考虑一下