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

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

最后的微服务列表中，既有被其他微服务使用的公共服务，也有彼此独立运行的业务服务。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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