01 | 到底什么是微服务？

精选留言(95)

• 

  Colin

  服务化最难的是在数据库层，因为数据库中很多数据都是相互关联的，比如用户用户跟订单，订单和商品等等这些数据之间都是有关联的，服务拆分之后会面临以下问题:1当需要读取关联数据时，如果采用表连接的方式查询数据会出现跨数据库查询的可能，2如果是通过RPC的方式多次调用(比如要查订单，就需要查询商品及订单详细信息)，也会出现多次调用导致的频繁多次的数据库连接，而如果使用缓存，也会面临数据库与缓存之间的数据同步问题，特别是数据库与缓存服务器都存在集群的情况下，会更难处理，这也是在做微服务之前必须要考虑的问题。

  作者回复: 是的，服务化拆分最好不要涉及跨数据库表交互

  2018-08-23

   2

   114
• 

  少帅

  看到留言里面好多正在经历从单体到微服务的拆分过程，拆分微服务先要把业务梳理清楚，做到心中有数，梳理清楚了那么业务的边界自然清晰了，自然而然对应拆分哪些服务也出来了，拆分的过程中一定是绞杀式的，新的需求自然放到拆分的微服务，老的逻辑按照优先级和重要程度一个点一个点的从单体迁移微服务，服务化上线之后，渐渐取代老的单体，等全部拆分完毕，线上稳定之后，自然就可以下掉老的单体应用

  作者回复: 实践出真知👍

  2018-08-23

  

   46
• 

  Neo_PJ

  现在的系统代码量50w，单体应用，但是拆分成微服务太麻烦了，领导不敢动，系统是金融管理基金托管计算的，太多复杂场景耦合，10几年的代码，好几个团队的代码堆积，俗话就是 又臭又硬的系统，只能不断维护，不敢重新搭建新的框架，不敢拆，拆不得，拆了谁负责，谁敢保证拆后所有功能按照原有一样逻辑呢？
  
  唉，老员工都是吐槽，继续码代码，分支也多，团队也多，部署一次1小时，每次有代码提交就催着部署，意味着系统动不动挂一小时，部署相当麻烦，文件对比，打包等等
  
  这个系统没救了

  作者回复: 不好整…

  2018-08-23

   2

   43
• 

  钟悠

  在我看来，用通俗的话来讲，服务化就是把传统的单机应用中通过 JAR 包依赖产生的本地方法调用，改造成通过 RPC 接口产生的远程方法调用。这句话真的讲的很透彻👍

  作者回复: 实践出真知

  2018-08-24

  

   20
• 

  YC

  看到有人说dao层要不要抽出来作为微服务，我觉得没必要，每个小应用都应该有自己独立的数据库，如果dao抽出来，意味着其他服务也可以调用这个dao，那就会造成数据库数据的混乱。最好是在dao层上面封装service层，提供给其他应用使用，这样能保证数据的读写可控

  2018-08-23

   1

   20
• 

  JKong

  看到老师提到微服务粒度，看到一个面试题是这样说的：微服务划分的粒度？
  这个问题，该从什么方面回答？

  2018-08-23

  

   19
• 

  云学

  这篇文章内容比较实在，〃进程内调用改成Rpc调用〃，一语直达本质，期待更多干货

  2018-08-23

  

   17
• 

  日拱一卒

  看了文章和留言，讲的很清楚，请教一个问题，之前也有同学问了。
  
  对于典型的复杂web应用，当由单体应用改造成微服务时，一般会按照业务进行服务划分，彼此独立的业务拆分到不同的微服务中。但是在数据层面，涉及到下面两个问题:
  1. 数据库是否拆分？从数据架构的角度看，可能有三个选择:1) 一个db实例，所有微服务在一个schema中，2) 一个db实例，每个微服务有自己的schema，3) 每个微服务有自己的db实例。我们在实际项目中应该如何取舍？
  2. DAO层是否拆分？可能有两个选择: 1) DAO层保持不变或者单独部署成微服务，所有业务微服务通过引用jar包或者HTTP的方式和DAO进行交互。2) 把DAO进行拆分，每个业务微服务内部管理自己会用到的db数据。在所有微服务采用的技术栈相同的情况下，上面哪种方式更可取？

  作者回复: 第一个问题：数据库拆分其实不是微服务拆分的关键，如果会引入分布式事务的话，最好不要拆分。
  第二个问题：长远来看，建议方案2，这样会减少每个微服务同db的连接，在集群规模上千台的情况下，db的连接数不会成为瓶颈，服务启动也会变快，因为初始化连接也会变少。

  2018-08-25

   1

   12
• 

  WolvesLeader

  老师，问一下，一般和数据库交互的dao层，是单独拿出来做成服务好还是不做好，还有一些公共的模块是不是也要做成服务呢？谢谢啦

  作者回复: 我理解你这个需求中间件的需求

  2018-08-23

  

   12
• 

  Amorfati

  如何确定是过度膨胀也是比较难的问题，在膨胀前切分很有可能随着业务的发展，发现切错了，然后好尴尬，按照我的理解是，单体应用中已经经过足够时间业务上的检验，将其中模式比较稳定，整体高内聚的业务进行抽离。如有错误，还请老师指正。

  作者回复: 对

  2018-08-23

  

   10
• 

  null

  5 年的 php 单体应用，整个项目结构复杂混乱，php 前端和 php 后端各种函数调用。业务逻辑代码也穿插着大量已过期或无关的代码，项目可维护性越来越低。每次需求开发完毕合并分支时，需要花费大量的精力去解决代码冲突。开发的速度远跟不上需求的速度。
  
  在去年所有新的需求使用 java 进行开发，同时一点一点将 php 的业务迁移到 java。
  从一开始就没规划好，一股脑喊出了微服务化口号，前期也是真苦了运维和测试。
  
  一年多过去了，项目现在的的状态：
  1. 项目内结构依旧混乱，A 模块和 B 模块都依赖于 C 模块，我们的做法是，A 模块里写一次 C 模块，B 模块同样写一遍 C 模块。其中有两个原因，无法实现分布式事务，只好放到同一个系统内，整个流程可以同属于一个事务；另一个原因是模块的边界划分是很模糊的。
  2. 项目之间的依赖关系就跟意大利面条一样，而且之间的接口，并没有想着去向下兼容，甚至发生过接口定义变更了，导致线上依赖的服务都无法正常提供服务。现在每次发布也是战战兢兢。
  
  目前面临最大的问题便是分布式事务的问题，导致 DAO 层的代码，重复散落在各个模块之中，真是令人头大。

  作者回复: 第一点，可以抽离出哪些是公共的模块，并且请求量和重要性值得这么做。
  第二点，接口定义最好不要随便变更，这是原则，可以添加参数，新增返回字段，也可以新增接口，但最好不要改参数名或者已有字段。

  2018-08-23

  

   8
• 

  cc

  我的理解，微服务的重点在于拆分治理，spring boot，容器，这些只是实现拆分的一个工具而已，如果你想，使用传统的tomcat启动发布也是可以实现这样的目标的。

  作者回复: 是的，微服务架构的核心在于服务治理，而容器是对运维方式的改变，通过容器标准化发布部署。

  2018-08-23

  

   6
• 

  常玉棋

  子系统越来越多，重复造轮子的情况也越来越频繁，但我以为小团队还是不要轻易采用微服务方案，毕竟，创业初期人员有限，应该以项目目标实现为第一要务。

  2018-08-23

  

   6
• 

  WestonLee

  我们目前的系统就是从单体到服务化再到微服务化的，第一次转变是为了减少大计算量的模块带来的阻塞，提高负载，第二次转变是因为系统已经比较庞大，需要切分的更细，并且便于开发维护。目前用了spring cloud和docker，遇到的最大的问题是数据库伴随服务的切分以及一致性带来的复杂度提升

  作者回复: 微服务有利有弊，总体来看，利大于弊

  2018-08-23

  

   6
• 

  jogin

  现在好多公司强推微服务，不考虑实际情况，单体应用并不是就一定很脆弱，系统不稳定，服务拆分了也不一定稳定，开发效率不高，没准是流程问题，系统本身设计问题耦合严重，单体应用设计不好，玩不转，服务拆分后更乱。
  
  
  有些开发就是为了研究微服务在内部推广，大家都想学一下然后就达成默契了。

  作者回复: 嗯，微服务架构的技术门槛非常高，没有充裕的技术人员不要轻易入坑

  2018-08-25

  

   5
• 

  Johnson

  我们现在再用微服务，但是服务之间产生的RPC调用过多 依赖依然很重，有时启动一个服务需要部署多个服务，这个怎么去优化

  2018-09-18

   2

   3
• 

  瘦是为了帅、

  以前都是接触的单体小项目，还没有遇到膨胀到不行的，目前在这里新公司，用到了微服务！多学习，多了解

  2018-08-25

  

   3
• 

  老王的老李头

  我弄不清楚RPC,跟RESTful有啥关系

  2018-08-24

   1

   3
• 

  70

  公司现在的系统采用了按功能进行划分，不同功能的模块，不同Service，不同Service之间依靠rpc进行通信，如果其他服务需要访问的不属于他的数据库，需要对应的Service提供出服务进行访问，这样会有一个问题，本来需要事物执行的逻辑可能会被打散到多个Service执行，那要不要在事物中包含Rpc调用，我的理解是不行的，这样可能会导致数据库事物卡着，那行怎么进行保证一致性喃？通过异步的去确认吗？

  2018-08-24

  

   3
• 

  青青木

  老师好，我所在的公司正在进行微服务化的系统改造，原有的系统是一个巨大的单体架构业务系统。在改造过程中我的困惑是微服务的拆分粒度 差的大了感觉效果不好，差的细了业务调用链太长 造成系统响应变慢 问题定位不容易等问题，老师您对微服务的业务划分有什么建议吗？谢谢

  作者回复: 下一节会讨论

  2018-08-23

  

   3