02 | 从单体应用走向服务化

精选留言(75)

• 

  oddrock

  我现在对拆分的考量：
  一是业务维度聚类，业务和数据关系密切的应该放在一起。
  二是功能维度聚类，公共功能聚合为一个服务。
  三是人员聚类，这是个实际中的考量，如果某几个业务就是这几个人比较熟，那么最好放在一起，未来开发部署都好办。
  四是性能聚类，性能要求高的并发大的和性能要求低的并发小的，要分开为不同的服务，这样部署和运行都独立，好维护。
  还请老师指教

  作者回复: 总结的很好，看得出来属于业务经验很丰富的。😁

  2018-08-27

  

   116
• 

  唐伯虎点蚊香

  纵向拆分和横向拆分感觉还是不太理解

  2018-08-25

  

   63
• 

  日拱一卒

  关于服务拆分策略，我理解在实际工作中应该是横向和纵向相结合的方式:
  1. 首先收集整理公用的模块，将其进行服务化处理，这是横向拆分。
  2. 其次根据不同业务之间的耦合程度，将相对独立的服务拆分到不同的服务中，这属于纵向拆分。
  
  最后的微服务列表中，既有被其他微服务使用的公共服务，也有彼此独立运行的业务服务。
  

  作者回复: 对，实际业务中这两种拆分方式一般是相互结合使用的，如果业务比较多分散，适合做纵向拆分。如果多个业务之间有公共模块耦合，适合把公共模块拆分出来，适合做横向拆分。

  2018-08-26

   1

   32
• 

  snakorse

  还有必须要解决的一个问题是 拆分后带来的跨服务事务的一致性问题

  2018-08-25

  

   18
• 

  jogin

  看评论感觉好多人不需要微服务。
  1.业务复杂度问题单体应用没能梳理清楚，微服务也搞不懂定。
  2.人手太少，微服务只会增加系统复杂度，运维成本，大家不要看到把原先的函数调用改成接口调用，没真正了解服务拆分后带来的系统复杂度。
  3.系统设计问题，代码写的乱，开发流程问题，不是微服务能解决的。

  作者回复: 对，微服务只能解决单体膨胀后的痛，但也会带来架构复杂性，要权衡利弊

  2018-08-25

  

   14
• 

  明天更美好

  我们是单体应用，一共22个接口，但是有一个接口并发巨大，二期势必拆分微服务架构。我觉得按照功能进行垂直拆分比较合适，我们之前有17个开发人员，现在裁员就剩下4个。希望胡老师给个建议

  作者回复: 4个人搞微服务，有没有基础架构人员？没有就算了吧……

  2018-08-25

  

   12
• 

  常玉棋

  我觉得目前单体能搞定的话就不要为了拆分而拆分，因为拆分后涉及到的问题有可能会让现有人员手忙脚乱，最好等做好了技术和人员准备再拆分。

  作者回复: 是这样的

  2018-08-25

  

   10
• 

  🤕 ～ 😮

  横向拆分:把一些不会和其他主业务有依赖的功能拆分出来，最典型的就是common。
  纵向拆分:按照业务来拆分，比如用户访问一个商城，从访问到下单成功会调用很多服务，我们可以把用户登录做一个服务，商城首页以及商品信息做一个服务，购物车模块是一个服务，支付模块又是另一个服务，这样整个商城都是微服务架构，不管哪个单独的服务出现问题，都不会影响别的服务，方便于技术人员最快定位问题，解决问题。
  准确来说，一个项目里边是横向和纵向都有的，并不冲突，微服务带给我们的好处有很多，但具体能不能使用微服务还要根据具体的项目和团队来决定。
  (以上拆分仅供举例参考，具体拆分视项目而定)

  作者回复: 对，视具体项目而定

  2018-08-26

  

   8
• 

  科大大👏🏻

  当公司技术人员不足时就没必要考虑微服务了，好好做好单体架构，但是做的同时也要考虑未来有可能过渡到微服务，所以如果明确了以后会变成微服务的话单体架构有没有什么设计标准呢？

  2018-08-25

  

   7
• 

  丢

  实际项目通常是横向和纵向拆分相结合，公共的服务单独拆分出来，然后上层业务按功能模块拆分

  2018-08-28

  

   6
• 

  Geek_8d2caa

  开始是10多人的团队，对业务进行了拆分，上线后，人员陆续离职，现在是6个人背着将近30个微服务，开发一个功能点，基本上所有人都得上，就演变成天天开会还解决不了问题，效率奇低……所以，有没有微服务退回到单体的做法？

  作者回复: 可以适当做服务合并

  2018-08-28

  

   5
• 

  lovedebug

  微服务对运维和运维架构要求很高，没有运维就搞微服务就是给自己埋坑。

  作者回复: 是的

  2018-08-28

  

   4
• 

  eason2017

  前期，可以稍微粗粒度一些。先进行纵向拆分，把基础功能（用户系统）独立部署以维护。其它业务功能关联不紧密的可以独立部署，可以看这些业务在公司发展方向的重要性
  后面，可以看清哪些功能是其他业务系统一定要调用的，同时，自身系统内也有其他繁杂的功能，那么可以进行横向切分，把被频繁调用的服务抽象并独立部署。

  作者回复: 对

  2018-08-25

  

   4
• 

  softtwilight

  横向拆分我的理解是就像aop，把共用但又跟其他部分不太相关的抽离出来，而纵向拆分是把高没聚的拆分出来

  2018-08-25

  

   4
• 

  少帅

  是否需要拆分要看目前公司项目的具体的情况，如果现有架构无法满足当前业务发展速度，比如构建一次要半天，上一次线经常搞通宵，牵一发而动全身，那么这个时候可以考虑一下微服务，拆微服务势必会提高运维、问题追踪、分布式事务等复杂度，所以微服务整个技术栈都要考虑进去

  作者回复: 嗯，搞不定微服务的技术栈就不要往这个坑里跳

  2018-08-26

  

   3
• 

  🇨🇳光🇨🇳

  目前根据业务 拆分出来了两个 独立服务 接口走rpc 调用 还在测试环境验证中！

  2018-08-25

  

   3
• 

  jogin

  没有推行微服务之前，单体应用的业务逻辑拆分，整体系统设计做得好，会给后期服务化改造铺平道路。

  2018-08-25

  

   3
• 

  yankerzhu

  纵向拆分类似于接口，横向拆分类似于抽象类

  2018-09-02

  

   2
• 

  🐢先生

  我们不要为了微服务而做微服务，做了服务拆分，我们会投入更大。个人觉得，做了服务拆分后，带来的最大的挑战应该是分布式事务，这个原因也导致了我们微服务的难落地。另外的话，大部分的初创公司不适合，需要结合公司自身的人员储备和业务情况等来综合考虑。

  作者回复: 是的

  2018-08-27

  

   2
• 

  jogin

  什么时候推行微服务，不同技术栈有区别，之前最多的一次4，50个php技术维护一个单体应用，整个系统结构，业务模块之间划分比较清晰，不同小组负责不同模块，开发上采用多版本并行开发，每个版本7，8个技术。这时候整个团队开发效率上没有太大问题，架构组把控非常好。

  2018-08-25

  

   2