这是一个创建于 2446 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近在考虑将项目拆分成一个个小模块，运行在 docker 里面，每个模块之间用 restful 的方式来通信，所以在考虑使用微服务的框架。
目前的项目主要用 php 开发的，前两天了解了下 sprin cloud，看到一篇文章说是只能运行 java 的项目，所以就没继续了。
对微服务了解不深，所以请问下有这方面经验的朋友，该如何选择呢？
 |
1
1762628386 2018-03-22 00:40:30 +08:00
慢死吧
|
|
2
1762628386 2018-03-22 00:41:12 +08:00  1
http 接口很慢的
|
 |
3
gdtv 2018-03-22 00:44:56 +08:00
@1762628386 可有解决办法或者更好的建议？
|
 |
4
Luckyray 2018-03-22 00:48:58 +08:00 via iPhone 1
spring cloud 的好处是有很多现成的工具让你使用，你可以看看它包含了哪些组件，如果你的系统不是很复杂庞大的话，可能有些工具是用不到的，完全可以手动撸一套 PHP 简单版出来。
微服务说白了就是拆分，但是可能本来业务就复杂，再拆一拆可能导致有几百个服务，成千上万个实例在跑，所以日志怎么收集，配置怎么统一更新，负载均衡怎么搞，服务提供方怎么找到服务使用方，需不需要熔断、升降级，一大票微服务的 api 怎么结合成统一的对外 api 等等。 |
 |
5
MrMike OP @1762628386 那用什么快些？所有模块都放在一起？单一应用。
|
|
7
Luckyray 2018-03-22 00:54:34 +08:00 via iPhone
@MrMike 这么一说的确没听过有现成的 PHP 框架……一提微服务就自动想 Java 了，不如换 Java ？😂
|
 |
8
Immortal 2018-03-22 00:55:31 +08:00
不知道楼主项目如何 之前也学习了很多关于微服务的知识 但是思前想后 自己手头项目还是没必要上微服务
还是老话 在考虑怎么用之前,还是先想想想是否真的需要 除了说出去比较时髦 还得考虑之后的维护成本 就像 4l Luckyray 说的 上了微服务 就得考虑很多东西了 如果对于项目帮助不是很大 真不如不上 |
 |
10
orangeade 2018-03-22 00:58:02 +08:00
可以考虑 RPC 通信或者消息队列啥的，微服务之间全用 HTTP+Restful 也没必要吧
|
|
11
orangeade 2018-03-22 00:58:47 +08:00
微服务有个好处就是解放语言选择的，不同微服务可以用不同的编程语言
|
|
12
Immortal 2018-03-22 00:59:10 +08:00 1
而且个人觉得 http 没有想象中的慢 服务之间调用 前期用 http 完全没问题的
|
|
13
MrMike OP @Immortal 只因为目前手上项目的原因想拆分，所以就想到了用微服务。现在的项目里面，也分了很多模块，每个模块之间的关联性很强，有时候修改一个 bug 可能会带出其他的问题，当然也跟程序员的技术水平有关系。所以想把各个模块独立出来，形成一个独立的应用，这样的话，模块出问题了，不至于影响整个项目的运行。
|
|
14
Immortal 2018-03-22 01:05:38 +08:00
@MrMike
从你的描述来看 感觉不是微服务不微服务的问题 是业务逻辑拆分不够干净 光讨论微服务 因为我自己也写 php 和 golang,微服务这块看的一直是 golang 方面的,php 我用 yaf 最多,通讯我一下子说的话就知道 yar 和 hprosed |
|
15
MrMike OP @orangeade 各个应用之间如何通信，这个没决定，RPC 和 RESTFULL 比较，RESTFULL 要熟悉些。目前比较迷茫使用哪些软件来搭建项目框架。zookeeper 用来注册和发现，docker 用来运行各个模块，目前是这样考虑的，因为不了解 zookeeper，所以担心研究了半天，最后像了解 spring cloud 一样，只适合 java 的项目就浪费时间了。
|
|
17
MrMike OP @Immortal 业务逻辑上是有点问题，项目的基础架构已经确定了，也开发了一段时间了，需求变化了，所以有时候为了赶时间，就没有那么严谨，导致现在业务逻辑比较乱，要是想去理顺，可能要花很多时间，所以就考虑把每一个模块拆分出来，然后逐步重构每一个模块，这样也不至于影响整个项目的运行了。
|
 |
19
artandlol 2018-03-22 07:14:44 +08:00 via iPhone
回复都是 etcd 这么底层的？ 当然是 Fabric8，集成 k8s 和 Jenkins 的一个框架
|
 |
20
sagaxu 2018-03-22 07:41:04 +08:00 via Android
@1762628386 手上有个日均 5 亿次调用的 http 接口，单就协议开销而言，单机 100 亿次调用也吃得消，http 性能是比不过二进制协议，也不至于慢死吧。
@MrMike 可以看看 swoole 和 swoole 之上的一些方案 |
 |
21
yuanfnadi 2018-03-22 08:02:06 +08:00 via iPhone
k8s 可以解决你的任何问题。
|
 |
22
p2pCoder 2018-03-22 08:22:51 +08:00 via Android
服务注册与发现中心推荐 consul
|
 |
23
helloworld12 2018-03-22 09:03:51 +08:00
@sagaxu 你服务器配置是怎样的？
|
 |
24
WinMain 2018-03-22 09:04:34 +08:00
spring cloud ? Dubbo ? 这两个用的最多吧，再加上一个 docker 的管理框架。
我们公司用的 spring cloud，感觉很好上手。 |
 |
25
feiyu1993 2018-03-22 09:09:58 +08:00
基于 swoole 的 php-msf 微服务框架考虑下。
|
|
26
p2pCoder 2018-03-22 09:12:01 +08:00
如果你要纯用 php 做微服务，包括 服务注册与发现，断路器 路由 网关 消息总线 配置置中心等所有功能，应该是很有挑战的
我现在大数据部门用 python 做数据模型 部署和一些实时爬取的服务，都是用 python 完成注册到 eureka 或者 consul，然后其他用 spring cloud 实现其他功能 |
 |
27
WinterWu 2018-03-22 09:17:18 +08:00
主要还是看业务本身，如果业务模型比较单一，用户容易区分，可以直接根据用户垂直切分，业务本身只需要根据需要简单扩容，这样只要在反代或者 LBS 上进行配置好规则，就很容易做到横行扩容。
|
 |
28
yuhuan66666 2018-03-22 09:28:19 +08:00
@1762628386 #2 有多慢，你扔下一句话就跑了有慢的例子么 到多少并发时候会出现瓶颈
|
|
29
yuhuan66666 2018-03-22 09:31:17 +08:00
@WinMain #24 请问 你们注册中心用的是 eureka 还是 consul ？ 有出现性能瓶颈吗？
|
 |
30
eccstartup 2018-03-22 09:31:40 +08:00 via iPhone
@yuhuan66666 嗯，已屏蔽这种不负责任的回答
|
|
31
yuhuan66666 2018-03-22 09:32:35 +08:00
@p2pCoder #22 请问推荐理由是啥？ eureka 呢？
|
|
32
p2pCoder 2018-03-22 09:38:15 +08:00
@yuhuan66666 eureka consul 都可以，相比 zk 可用性和恢复能力都更好
|
 |
33
jowuIM 2018-03-22 09:41:39 +08:00
为什么一定要微服务，真的需要吗？
|
 |
34
jyf 2018-03-22 09:46:41 +08:00
其实我觉得这些技术选择倒不是重要的 重要的是如何拆接口到不同的服务去
|
|
35
yuhuan66666 2018-03-22 10:00:50 +08:00
@p2pCoder #32 感谢
|
 |
36
lauix 2018-03-22 10:24:10 +08:00
可以考虑 RPC
|
 |
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。 服务化会带来新的问题：问题排查、各种服务监控会变复杂。 |
|
38
WinMain 2018-03-22 10:46:38 +08:00 1
@yuhuan66666 你的用户场景是？我们 app 日活不到千万，完全没问题。在没有碰到性能问题的时候，就不用考虑性能问题了，考虑 spring cloud 这个框架有多少大公司在用就可以了。
|
|
40
MrMike OP @p2pCoder 不是用 PHP 做纯的微服务，前几天一直在网上查，一查微服务，基本都是 spring cloud or zookeeper，后来还尝试安装了下 spring cloud，但是看到一篇文章说 spring cloud 只支持 java 的程序，我就不敢继续尝试下去了，因为时间消耗不起。
|
|
41
p2pCoder 2018-03-22 11:00:37 +08:00
@MrMike 首先了解服务注册发现与健康检测，这个和语言没有关系，zk eureka consul 都可以，eureka consul 都是 http restapi 接口完成相应功能的，和语言无关
|
 |
42
hlwjia 2018-03-22 11:07:15 +08:00
微服务做起来比说起来难多了，实际操作起来绝对比 monolithic 难多了，我说的还不是技术方面的难
而且大多数公司的业务都用不着微服务，用了反而麻烦；对每个工程师要求也更高，要不是技术牛逼的团队，只会越搞越糟 不如 现在的流程里加强 code review 什么的 |
|
43
MrMike OP @WinterWu
@yuhuan66666 @nullen @lauix @feiyu1993 @p2pCoder 感谢各位朋友的推荐。看到大家说了这么多，我都有点迷茫，是否真的需要使用微服务了，或许是我的帖子内容没说清楚。 我的初衷其实很简单，就想把现在单一的应用里面很多模块拆分出来，形成一个独立的模块应用，然后模块之间采用一种合适的通信方式进行数据的交互，模块我是打算用 docker 来封装，每一个模块应该都有独立的数据库，这样的话，就算单独运行某一个模块，也都可以使用的。 另外还有两个原因就是： 1，团队的技术水平不一样，但是项目进度又摆在那里，有时间上的要求，不想一个新的开发人员为了开发一个小功能，去花时间学习新的框架，如果能用他们熟悉的框架或方式来实现，这样可以节省时间，然后再逐渐完善。 2，现在的单一系统，修改一个问题，可能会涉及到很多模块的应用，数据库之间的关联性又特别强，有时候修改完后，测试员不够的情况下，没检查仔细，部署上去，就出问题了。 |
 |
44
abcbuzhiming 2018-03-22 11:10:49 +08:00
微服务不是银弹，微服务的本质是业务拆分和接口治理，特别是业务拆分，拆不好就完蛋，对于中小型项目，微服务其实付出了额外的代价
|
|
45
abcbuzhiming 2018-03-22 11:14:30 +08:00
@MrMike 之前有篇文章说过一句话：微服务首先是组织架构，然后才是技术架构，它不是“团队技术不行时的选择”，它对整个团队的水平要求其实是提高了而不是降低了。
单一应用的规模如果不够大的话用微服务其实没有优势 微服务对测试和部署的要求其实更高 |
|
47
nullen 2018-03-22 11:30:56 +08:00
@abcbuzhiming 赞同。
|
|
48
WinMain 2018-03-22 11:32:06 +08:00
@MrMike 不知道有没有公司自己改的，也不太清楚官方有没有提供这种小办法供其他语言。暂时都是用 spring boot。
|
 |
49
wqqdhero 2018-03-22 11:32:30 +08:00
建议用 RPC 通信
服务治理和部署很难搞 如果是中小型 不太推荐 没啥必要 要付出很多额外代价 |
 |
51
feverzsj 2018-03-22 12:06:30 +08:00
微服务只适用于超大规模电商场景，其他 99.9%的业务场景都不适合
|
 |
52
tairan2006 2018-03-22 12:33:30 +08:00
微服务只适用于大规模系统。
微服务会带来很多问题，比如分布式事务、CQRS 啥的，一个人能写的项目用微服务是作死。 |
|
54
nullen 2018-03-22 13:06:02 +08:00
@myyou 嗯，HTTP2 和 HTTP1 差别蛮大的。
包括前几天 Nginx 开始支持 gRPC，我觉得 gRPC 在实际中的应用案例会越来越多。 |
|
55
MrMike OP |
 |
56
amon 2018-03-22 14:56:52 +08:00
上面很多都对微服务妖魔化了。
我个人觉得微服务对于中小项目也挺适合。 系统架构：单机 -> 集群 -> 微服务 一开始不一定要迈那么大步子，比如能将现有的单机架构的项目拆分为多个业务逻辑解耦的子项目。 |
 |
57
wellsc 2018-03-22 14:59:46 +08:00
架构 != 框架
|
 |
58
tanszhe 2018-03-22 15:12:24 +08:00
把问题复杂了，大方向朝着简单化发展就行。在一个项目觉得太复杂了 可以把独立性强的拆出来通过 http 接口来调用。当拆出来的模块比较多了之后 而且 运行每个服务的机器也比较多了 就需哟搞个注册中心 来统一管理各个模块了 一步步慢慢来，这些方案成熟的很，什么语言都无所谓 原理都一样
|
 |
59
csl1995 2018-03-22 15:36:38 +08:00
将现有的系统微服务化的话，成本太高，如果系统不大不复杂还行，如果系统庞大那难度真的很大，不亚于将整个系统重构。如果这种情况的话建议还是多考虑下吧。
如果新开始一个系统确实可以考虑使用微服务，不同的模块使用不同的技术栈，后期的维护升级也相对于要简单(招对应技术栈的人即可)。 |
 |
60
RainFinder 2018-03-22 15:44:38 +08:00
说 http 慢的，你们还停留在 1.1 ？再说 restful 本就是为 http 设计的
|
 |
61
q397064399 2018-03-22 15:48:58 +08:00
|
 |
62
est 2018-03-22 16:13:43 +08:00
一般说微服务就是 rpc 没的跑。基本等价于 grpc。
|
 |
63
qdcanyun 2018-03-22 16:30:35 +08:00
微服务，调用链分析，服务发现，限流，熔断，负载均衡了解下。
先尝试解耦你的 monolith 项目，如果 monolith 里的各个模块做不好单一职责，微服务照样也设计不好单一职责。 先搞定单一职责，然后根据业务分组部署，快速部署，然后垂直拆分，最后再考虑服务化。 「团队的技术水平不一样」问题，靠修订招人标准来解决，小团队除非是大牛，否则尽量招技术栈接近的人然后在一个技术栈上快速跑起来 「现在的单一系统，修改一个问题，可能会涉及到很多模块的应用，数据库之间的关联性又特别强，有时候修改完后，测试员不够的情况下，没检查仔细，部署上去，就出问题了。」 单一职责解耦，Code Review，自己写测试，灰度发布，蓝绿部署，多靠可具体执行的系统方案来解决问题，不要依靠人来解决稳定性。（测试员是什么鬼。。。。 |
 |
65
cenphoenix 2018-03-22 21:13:15 +08:00
怎么现在貌似动不动就说要上微服务，真有那么大的访问量用得上微服务吗。
|
Select Language