多少并发量才值得用分布式？ 微服务的意义是什么？是不是一定要高并发才用？
Kraken · KrakenMing · 2018-05-15 23:01:48 +08:00 · 12302 次点击这是一个创建于 2387 天前的主题，其中的信息可能已经有所发展或是发生改变。
今天跟同事意见有一些分歧，也引发了自己一些思考，想问问大家 大家都什么情况下用的 spring cloud 这款框架，微服务的意义到底在哪里 除了解决高并发问题外，还有哪些优点？到底什么情况下才适合用 spring cloud
第 1 条附言 · 2018-05-16 15:30:32 +08:00
另外分布式和负载均衡怎么选择？各自的利弊是什么？
 |
1
iwdmb 2018-05-16 00:16:52 +08:00
私以為 Microservice 最重要的是拆分，把一大佗綁在一起的系統拆分成小的單元。
|
 |
2
agagega 2018-05-16 02:00:16 +08:00 via iPhone
项目太大了，不同的团队存在，才有必要。一个人还搞这个那不就是找死吗。
|
 |
3
q397064399 2018-05-16 06:59:19 +08:00  4
微服务 无关于技术，仅仅是业务架构上的一种诉求。
所有微服务架构能解决的问题，单体应用架构都能解决，而且解决的非常好。 你只有进公司 做过大型项目，跟各种后端团队合作，一堆乱七八糟的业务逻辑跟产品诉求 才能明白微服务的意义，因为造摩天大楼跟造小狗窝 是完全不一样的工作。 开发人员选择使用微服务，最大的好处就是 处理系统边界的问题， 这个系统边界 指的便是代码逻辑的边界， 微服务正是遵从了被所有开放人员奉如圭泉的经典理念 关注点分离原则 -> 分开是为了更好的相聚 被业界吹捧如此  如果贵司的服务调用是这样.. 我建议还是不要搞微服务了，因为整个系统边界很模糊，职责也分不清楚 当然我们架构师还是很努力的在演化，明确业务跟系统的边界 |
|
4
q397064399 2018-05-16 07:04:09 +08:00
无论是设计模式，SOLID 原则，所有在代码结构上的 一些编程原则以及各路大师们的总结
最终目的都是追求 关注点分离 这个目标， 因为关注点分离开来 ，能让整个系统更加清晰 ，让开发人员更易于理解 整个系统 让整个系统更易于修改，不会出现 牵一发而动全身的情况 |
|
5
q397064399 2018-05-16 07:09:35 +08:00
另外在微服务架构下，软件系统中的很多非固有复杂性，已经在慢慢被解决掉，业内也有非常多的可靠的方案，
像可靠事务消息系统 很多大公司 都有自己一套成熟的技术框架，完全不侵入业务 像熔断 网关 负载均衡 在云服务上 有更多成熟的选择 |
|
6
q397064399 2018-05-16 07:14:23 +08:00
如果楼主有疑问，或者不解，可以读一读 人月神话 -> 关于 软件中的固有复杂性与次要复杂性的解释
|
 |
8
Kraken OP @q397064399 但是如果微服务的东西都可以用单体应用来解决的话 那为啥还要用微服务？多一个微服务不就要多一个 tomcat 这样弊大于利啊
|
|
9
q397064399 2018-05-16 11:01:14 +08:00 1
@Kraken #8
这句话也是有前提的，针对 在业务逻辑并不是特别负责的情况下， 另外所谓高并发 也可以通过 RateLimitter 令牌桶 之类的库来做限流，并不是说一定要上微服务 才能解决高并发问题，另外单体应用也可以部署多个实例 作为备份， 每个实例并没有保存状态， 当单台实例出现问题，，备用实例也可以顶上 |
 |
10
mashiro233 2018-05-16 14:32:51 +08:00 via Android
我认为微服务的概念实际上和软件开发中追求的高内聚低耦合是一个目的。就是为了避免各个模块之间的过渡依赖，制定清晰的接口，只不过这个模块被放大了成了业务，就成了微服务。
就像 @q397064399 说的那样，微服务的最大意义是在于对待处理系统边界的问题，使得业务 /模块易于拆分，业务之间仅关注于接口而不是实现。微服务能够解决的不仅仅是高并发问题，还能解决开发问题。 举个例子，现在流行 restful 架构就是很好的一种拆分方式。前端在进行开发的时候，完全不需要关注后端的实现。前端只要写完逻辑，做好单元测试接口测试就完事了。管他后端是 PHP 还是 Java，何必自寻烦恼。 至于楼主提到多个微服务就要多个 tomcat 吃资源的事情。首先这个利和弊是要根据客观条件来判断的。当我们的业务只需要通过增加服务器资源，几乎不需要修改代码就能解决高并发的时候，我认为老板还是很乐意看到这种情况的。当然，如果你们根本就没有这么大的业务量，平白无故的开几个 tomcat 确实吃资源。同样，制定接口和拆分业务也需要占用开发时间。如何进行取舍，怎么进行合理的拆分，这个就是架构师的活了。 |
|
11
Kraken OP @q397064399 @mashiro233 首先谢谢两位大佬解答，但是我还是有不懂的地方，就是负载均衡和分布式的区别，因为我身边的同事几乎很少会 spring cloud 的，而项目经理也说，并发问题可以通过负载均衡来解决，那么像 zookeeper，dubbo，eureka 这些分布式框架的意义何在？因为我刚从成都回来，成都那边确实很多公司都要 spring cloud，我估计深圳杭州那边可能会对 spring cloud 要求更高？如果说只有项目量级达到淘宝京东这种级别才用得上 spring cloud，那为何需求会这么大？另外负载均衡也是通过增加服务器就可以解决并发问题，但是 spring cloud 却会高出很多的人员成本，那到底 spring cloud 或者说 dubbo，zookeeper 这种分布式框架应该什么时候用？跟负载均衡比又有什么样的优势呢？
|
|
12
mashiro233 2018-05-16 17:18:45 +08:00 2
@Kraken
分布式和负载均衡，简单的说就是多个服务器跑不同的项目和多个服务器跑相同的项目。举个实际的例子。 因为我是做游戏服务端开发的我就用游戏举例子。魔兽世界知道吧，我们都知道魔兽世界有很多个区服，玩家通常都会选择不需要排队，延迟低的区服。所以，如果我们把游戏的逻辑服务端看成一个业务，通过增加多个服务器来跑游戏的逻辑服务端提供多个区服，这个就是负载均衡，用来解决服务器压力。 同样的，刚刚说的是以游戏服务端这个看成一个业务，然而一个完整的网络游戏可不止这么一个业务比如我们需要有一个公用的账号系统，因为我不可能换个区就要重新注册一个账号。我们还需要日志分析，用户行为分析，GM 工具等等各种其他的业务，这些业务肯定是跑在其他服务器上的，那么由这一堆业务所组成的完整的游戏运营服务，这个就是用分布式，用来解决模块的过度耦合。 然后，楼主你有一个误区，就是分布式主要是用来解决高并发或者其他因为系统资源不足所导致的瓶颈，这是错误的。我个人的观点是，分布式主要解决的是模块重用和系统边界问题，注重的是业务问题。依旧用上面那个例子，假如我们不采用分布式开发游戏整体业务，把账号系统在逻辑服务端里实现，那么就会出现换个区需要重新注册账号的问题。 |
|
13
Kraken OP @mashiro233 你这么说我就有点清晰了，不过还是觉得你说的这个优点，代价有点高，可能是我没接触过太大体量的项目，不过还是多谢大佬指教了！
|
 |
14
WEAlex 2018-06-04 15:03:50 +08:00 via Android 1
楼主关于启用多个 tomcat 对资源的消耗，可以去了解一下 docker。
|
Select Language