微服务架构盛行，微服务分分合合很常见，大家的微服务系统都是如何设计和演进的？

MartinFowler 在他几年前的文章中推荐单体优先的原则，如果不确定该不该拆，那就先不拆，等有必要的时候再拆，以演进的思路来看待微服务的拆分。


结案。

我的经验就是，小公司别折腾什么微服务，没必要。

其次是水平不行也别整什么微服务，之前接受过一个号称微服务的项目，最基本的 ci/cd 、分布式事务、链路追踪、日志采集都没有，开发偷懒一个 userDao 类在各个服务里都 copy 了一份（所有微服务数据库都落在了一个 db ）。共事了一段时间才发现，相当一批人对微服务的架构仅局限于注册中心+远程调用这块。

个人感觉针对现有项目进行改造的话，单体优先比较实用一些。
新项目的话采用 DDD 的思想来划分比较合理。

拆不一定要拆服务，就算是单体应用，只要业务、包、模块，这些东西划分的好，完全没必要拆。你要想拆是解决什么问题，一般主要解决的都是某个业务水平扩容与单体应用水平扩容的矛盾，基于其他目的来拆，都是耍流氓

某些小公司：开发一个就没几个人却偏偏：微服务、k8s 、自动化运维、敏捷开发全都搞一遍！

借楼问一下，一般情况下，什么样的场景（或者数据量、用户量、并发量）下才需要把单体拆分成微服务呢？有没有个大概的参考线？

@devswork

当你 **产品的用户告诉你** 他们有两三个服务中心要冗余备份但统筹管理，你的产品满足不了需求的时候。

而不是「为了方便将来能卖给」 有这种规模的用户而提前用上这样的架构



toC 的话，约等于，「用户没在微博上发网站怎么挂了」，就别用，用不上。

之前拆了.现在大多合成一个了.而且啥 dto,啥分层,啥 repo, 啥啥啥的都没了.现在单元测试,脚本一个文件模块梭哈
要说拆出来的服务.就是各方依赖.一搭眼就看来的基础服务.比如权限服务,状态服务之类的.没啥理由为什么拆.

@Chinsung 666 ，我之前的架构就是这样的，单体，但是划分好业务，随时可以拆成微服务，当然前提是数据库先拆分不同库，这样想耦合查询库都不行😂，后面随时都可以拆分成微服务。
@a90120411 DDD 是个好东西，但是 DDD 跟微服务的是一样的，还是不好划分领域边界，还是遇到粒度问题。而且 DDD 每个人看到都有点差距。另外很多餐桌鸡 不是说用 DDD 的思想去拆分微服务，而是把 DDD 的编程模型 也引入进单个微服务中，开发起来头大，反正水平差 的太多了。

难道不是从写 PPT 开始的么？

我前公司，我和 2 个开发，我负责 angular ，go ，运维。构架是 4 个 golang 单体服务，3 个单体 php ，两个前端管理页，两个官网，数据库同一个。

现在团队解散了，目前由我来运维机器和兼职需求开发，老板还找了两个后台兼职开发。最近转 ack 了，为什么呢？

因为考虑架构问题，而且因为现在没有专人维护 php ，但是需求还在加，老板找了很多兼职的，但是没人能看懂代码（主要是业务逻辑复杂又没文档，加上框架是 yii1 ）。

所以上 k8s 第一个好处就是新需求可以按模块开发。因为外包人员比较杂，不同的人有不同的思路和想法，所以中间也出现了现有的外包发现之前人对于业务设计有问题，不能扩展，代码质量极差，一旦完成需求就基本处于不可改的状态（我掌控不了这些，老板说的算）。所以按模块开发的话可以让他们在不影响别人的功能下自由发挥，日后如果要改也不会出现改一个地方就全蹦的状态（别笑，现在就是）


第二是维护方便。因为我虽然离职了，但是还是在维护服务器会出现的问题。比如 redis 他们开发只会写，从不设过期，导致经常崩。mysql 和代码是装在一起的，mysql 负载上去了之后服务器卡的不行。日志经常把磁盘写满，我还要上去删日志（写日志的方法是在程序里的，后面我自己去掉了），磁盘满了还会导致 redis 持久化问题（加上上面说的不设过期👏，我裂开），还有等等问题

现在买了阿里 mysql 和 redis ，再加上 k8s ，运维的问题省心了很多，mysql 和 redis 移除去后，服务器配置还能降低点，加上 ack 不要 master 的钱，不仅省心省力，成本还低了


第三我们的服务有要给客户离线部署的需求，经常性的。这个在刚入职的时候用的是虚拟机，不仅麻烦死，性能还低，有的客户不允许用虚拟机，还要给客户服务器搭环境，累的要死。

现在就好了，客户不用 aws 的 k8s 或者阿里的 k8s 的话我就装一个 k3s ，用 helm 一键就装上了。简直不要太爽。


第四我对于 go 和 k8s 还处于学习阶段，后面我会把旧 php 的项目重构成 go ，期间可以学到到微服务相关内容，对我肯定好处多多。


上面说的什么 ci/cd 、分布式、链路，日志。现在根部都不需要这些，等你要上，环境也有了，还不是分分钟的事？上面外包做的就是模块开发，模块间用 http 在 k8s 里面链接即可，反正是 toB 项目，性能压根不用考虑。

所以简单说就是：
1 、防止外包间互相拉屎导致单体项目不可用。
2 、维护方便
3 、搭服务方便（ 5 分钟，一键安装，费用到手）
4 、自我学习

微服务现在的状态，还是以为咨询公司提供赢利点为主。对 90%的公司的场景，单体很好。

@Chinsung 赞同，另一个角度还是要看复杂度，业务复杂度，团队大小（开发协作的复杂度），是否有复用需求
业务复杂度一般，团队不太大，协作也没有任何问题，单体的优点还是很多的

@devswork 讨论微服务拆分时机，从问题出发更好，如果单体架构也没有啥问题，当然也没必要非要引入微服务，徒增复杂度。

微服务的好处很多，但确实实施要求也高，所以在问题足够复杂的时候比较适合，比如：
1. 业务非常复杂，业务知识就多，放在一个单体服务里，知识的传递和上手本身就很困难。
2. 代码量很大，大几十万或上百万行代码，编译、排查问题都很耗时。技术上我们可以通过一些包级别的隔离尽量做到清晰，但实际操作难度也是不小的，毕竟开发人员水平各不相同，日常开发实现功能优先级更高，写代码图方便的也不在少数，所以单体越大内部耦合越严重，表现出来线上的稳定性非常差。
3. 团队逐渐变大，一起写代码，在一个单体上开发，提交 merge 的冲突比较多。人多了分小组，即便每个小组可以有专门的职责，在一个单体上开发，可以触碰到所有的代码，改动的冲突也会比较多。

开弓没有回头箭，单体往微服务迁移，还是要多方权衡，是否足够复杂，是否团队自己能搞定拆分之后的各种问题：
1. 尽量多的自动化，CI/CD ，自动化测试等
2. 上线后排查问题涉及多服务会更复杂，监控等手段得跟上
3. 多服务之间的契约稳定性保证，避免单方随意修改契约
4. 分的越多，职责越多，团队是否有足够的人来管多个服务

刚开始一把梭，梭完就知道哪些需要拆分成微服务了