#胡说八道 https://twitter.com/xuwenhao/status/1593469165892820992 我师兄把这条长推发给我，我也认真读一下，随便说说看法。我的立场是这样的：微服务这种没有严格定义的东西，很大程度是从业人员创造出来的伪经，没啥好讨论的。
TL;DR 把这一长串读下来，我还是觉得我没办法区分什么“服务化”和“微服务化”。如果不能区分这两者，那所谓微服务化带来的问题怎能判断不是从服务化开始就有了呢？
也不知道过去几年这股奇怪的“微服务”风潮是怎么起来的。在我看来，微服务的适用场景非常有限。
我15年入行的第一家公司也在16年初开始搞微服务（当然其实我开始工作的时候那家公司的搜索接口跟普通商品页[Java]接口就分拆出来单独用 Python 应用部署，已经是异构服务，非常微服务），后来我去了滴滴，在滴滴云做开发，滴滴云当然是微服务，它包括两大部分——我们团队掌握云服务的核心技术——复杂的计费规则，另一部分就是各种虚拟化产品，不同虚拟化产品也会有不同团队开发。后来我来到敝司，敝司也是电商公司，2020年-2021年两次大重构一直都在拆分之前的巨型单体服务。敝司的情况有点不同就是它的重构伴随着组织的重构，技术只是其中一小部分因素。综上，就我个人经历而言，微服务风潮至少在我入行以来就开始了，并且刚好都很适合我工作过的几间公司。
在我看来，大型系统的开发，核心的挑战其实只有一个，就是“控制复杂性”。
这句话没毛病。
事实上，过去几年这些问题，其实根本不是拿着高薪资的软件工程师们解决的。大部分是靠硬件解决的。
这个观点就见仁见智了，到底有多少问题是硬件解决多少问题是软件优化解决，我没有数据。但问题是微服务是用来解决“高并发”和“大数据”的么？我觉得接下来的两个推都跟微服务没有什么关系。
那当我们回到业务系统之后，其实面对的核心技术问题，就是“如何管理复杂性”。
直到这条推，作者才回到主题去讨论微服务。
而“微服务”，就是过去一段时间，很多公司采用的“控制复杂性”的解决办法。
我还是挺认同这个说法的。至于“微服务”是否能很好地“控制复杂性”，这是后文分析的重点。
于是，两边服务，都需要有对应的接口和实现，去完成这样的状态同步。这个过程中，就容易引入数据不一致的问题。只不过，这个不一致不是我们通常说的分布式共识问题。而是业务带来的潜在数据不一致的风险。
不过，这个问题在服务化的系统下，还不是个大问题，因为服务的边界是清晰的。只要各个团队自己有合理的日志，排查问题并不困难，排查问题的责任划分也非常清晰。
不过这个问题，在微服务下，会变得复杂或者并没有那么容易处理。
这里作者说服务化会有业务带来潜在数据不一致的风险。我很困惑这种问题为什么服务化系统可以很好解决，而微服务下会变得复杂和不容易处理。两个疑惑的点：一、怎样区分服务化系统和微服务化系统？二、为什么微服务化系统会变得更复杂更不容易处理？
以我本人的经验说一下为什么我会有这种困惑。我在敝司最初负责营销活动服务开发。这个服务包括两个组件：一个后台系统组件，地推人员可以通过这个系统配置优惠券和优惠活动；一个计算/使用优惠的核心组件，上游（支付系统）传入用户信息，核心组件判断用户能使用哪些优惠、用户使用了优惠的情况下更新支付金额更新用户的优惠使用情况。
这个营销活动服务算服务化系统吗？还是算微服务化系统？这两个组件后来还分拆成两个单独的库，这个时候它们又怎么算？无论是分拆前还是分拆后，处理营销问题的 bug 都要求我们小组在两个组件的日志之间跳来跳去。而且还需要我们考虑用户使用优惠时，地推人员在后台系统更新优惠配置这种麻烦问题——这个问题无论怎么组织，即使把两个组件做在一起，都很麻烦（当然麻烦可能就变了，如果做在一起就不用锁数据表）。
这个（指 不同的服务，就会面临一个“向前兼容”的问题）在服务化下也还好，因为服务之前的调用链路短，依赖关系少，但是在微服务下会严重地被放大。
没明白为什么微服务下会被严重放大。我想了一种情况，一个服务 A 通过100个服务之后跟某个服务 B 有关系。然后服务 A 改一个参数就能影响 B。这种情况确实很严重，但问题是服务 A 本来就应该只影响跟它直接关联的服务。把服务关系搞得跟蜘蛛网一样复杂，那换成巨型单体服务也搞不定。
极端情况下，我们完全可以把正则表达式匹配变成一个微服务，来避免不同语言正则表达式引擎支持的差异。
相信到这里，很多人的Bullshit Detector应该被触发了。为什么我们做一次正则表达式匹配，要去调用一次RPC？
这个论述多少有点竖稻草人了。说到这里就不能不绕回我最初的立场：怎样才算微服务化？没有明确的定义啊。
这样弱化的，缺少业务含义的微服务带来了两个新的问题。第一，这个微服务可以由谁来维护？第二，这个微服务可以由谁来调用？
作者认为为了维护这些缺少业务含义的服务专门找一组团队来干，会让这些服务进一步退化，跟业务更无关。但问题是为什么要跟业务有关？有钱砸一个 application infra 团队真的不好吗？还是以我贫瘠的从业举例，敝司 app infra 团队维护了一个提供唯一 id 的服务，这个服务为已经分库分表的服务提供唯一 id，这样的服务需要跟维护但是它跟业务真的一点都不搭界。
第二个问题作者认为如果谁都可以调用，那么最后这个服务也要考虑向前兼容性。对此我没有什么异议。
一个好的大型系统的设计，一定是当需要做迭代和改动的时候，很容易判断和知道应该在哪一个环节做修改。
这个也是服务化带来的价值，而进一步微服务化，往往非常容易破坏这一点。
我还是有两个疑问：1. 怎样区分服务化和微服务化（这个问题从一开始就存在）；2. 为什么微服务化反而不容易判断需要修改的环节？
回到微服务，在我看来，他并没有解决软件开发的“控制复杂性”这个核心问题。而只是在尝试不停地“转移复杂性”，并且在这个过程中，非常容易“增加复杂性”。
微服务真的只是在“转移复杂性”吗？如果换成“分解复杂性”是不是更贴切。但微服务是“转移复杂性”还是“分解复杂性”，真的就人嘴两张皮，反正都是理。
真正适合用微服务的场景非常少，要么就是巨头的核心业务，要堆上几百几千人研发团队的情况。
我对此没有什么异议。
TL;DR 把这一长串读下来，我还是觉得我没办法区分什么“服务化”和“微服务化”。如果不能区分这两者，那所谓微服务化带来的问题怎能判断不是从服务化开始就有了呢？
也不知道过去几年这股奇怪的“微服务”风潮是怎么起来的。在我看来，微服务的适用场景非常有限。
我15年入行的第一家公司也在16年初开始搞微服务（当然其实我开始工作的时候那家公司的搜索接口跟普通商品页[Java]接口就分拆出来单独用 Python 应用部署，已经是异构服务，非常微服务），后来我去了滴滴，在滴滴云做开发，滴滴云当然是微服务，它包括两大部分——我们团队掌握云服务的核心技术——复杂的计费规则，另一部分就是各种虚拟化产品，不同虚拟化产品也会有不同团队开发。后来我来到敝司，敝司也是电商公司，2020年-2021年两次大重构一直都在拆分之前的巨型单体服务。敝司的情况有点不同就是它的重构伴随着组织的重构，技术只是其中一小部分因素。综上，就我个人经历而言，微服务风潮至少在我入行以来就开始了，并且刚好都很适合我工作过的几间公司。
在我看来，大型系统的开发，核心的挑战其实只有一个，就是“控制复杂性”。
这句话没毛病。
事实上，过去几年这些问题，其实根本不是拿着高薪资的软件工程师们解决的。大部分是靠硬件解决的。
这个观点就见仁见智了，到底有多少问题是硬件解决多少问题是软件优化解决，我没有数据。但问题是微服务是用来解决“高并发”和“大数据”的么？我觉得接下来的两个推都跟微服务没有什么关系。
那当我们回到业务系统之后，其实面对的核心技术问题，就是“如何管理复杂性”。
直到这条推，作者才回到主题去讨论微服务。
而“微服务”，就是过去一段时间，很多公司采用的“控制复杂性”的解决办法。
我还是挺认同这个说法的。至于“微服务”是否能很好地“控制复杂性”，这是后文分析的重点。
于是，两边服务，都需要有对应的接口和实现，去完成这样的状态同步。这个过程中，就容易引入数据不一致的问题。只不过，这个不一致不是我们通常说的分布式共识问题。而是业务带来的潜在数据不一致的风险。
不过，这个问题在服务化的系统下，还不是个大问题，因为服务的边界是清晰的。只要各个团队自己有合理的日志，排查问题并不困难，排查问题的责任划分也非常清晰。
不过这个问题，在微服务下，会变得复杂或者并没有那么容易处理。
这里作者说服务化会有业务带来潜在数据不一致的风险。我很困惑这种问题为什么服务化系统可以很好解决，而微服务下会变得复杂和不容易处理。两个疑惑的点：一、怎样区分服务化系统和微服务化系统？二、为什么微服务化系统会变得更复杂更不容易处理？
以我本人的经验说一下为什么我会有这种困惑。我在敝司最初负责营销活动服务开发。这个服务包括两个组件：一个后台系统组件，地推人员可以通过这个系统配置优惠券和优惠活动；一个计算/使用优惠的核心组件，上游（支付系统）传入用户信息，核心组件判断用户能使用哪些优惠、用户使用了优惠的情况下更新支付金额更新用户的优惠使用情况。
这个营销活动服务算服务化系统吗？还是算微服务化系统？这两个组件后来还分拆成两个单独的库，这个时候它们又怎么算？无论是分拆前还是分拆后，处理营销问题的 bug 都要求我们小组在两个组件的日志之间跳来跳去。而且还需要我们考虑用户使用优惠时，地推人员在后台系统更新优惠配置这种麻烦问题——这个问题无论怎么组织，即使把两个组件做在一起，都很麻烦（当然麻烦可能就变了，如果做在一起就不用锁数据表）。
这个（指 不同的服务，就会面临一个“向前兼容”的问题）在服务化下也还好，因为服务之前的调用链路短，依赖关系少，但是在微服务下会严重地被放大。
没明白为什么微服务下会被严重放大。我想了一种情况，一个服务 A 通过100个服务之后跟某个服务 B 有关系。然后服务 A 改一个参数就能影响 B。这种情况确实很严重，但问题是服务 A 本来就应该只影响跟它直接关联的服务。把服务关系搞得跟蜘蛛网一样复杂，那换成巨型单体服务也搞不定。
极端情况下，我们完全可以把正则表达式匹配变成一个微服务，来避免不同语言正则表达式引擎支持的差异。
相信到这里，很多人的Bullshit Detector应该被触发了。为什么我们做一次正则表达式匹配，要去调用一次RPC？
这个论述多少有点竖稻草人了。说到这里就不能不绕回我最初的立场：怎样才算微服务化？没有明确的定义啊。
这样弱化的，缺少业务含义的微服务带来了两个新的问题。第一，这个微服务可以由谁来维护？第二，这个微服务可以由谁来调用？
作者认为为了维护这些缺少业务含义的服务专门找一组团队来干，会让这些服务进一步退化，跟业务更无关。但问题是为什么要跟业务有关？有钱砸一个 application infra 团队真的不好吗？还是以我贫瘠的从业举例，敝司 app infra 团队维护了一个提供唯一 id 的服务，这个服务为已经分库分表的服务提供唯一 id，这样的服务需要跟维护但是它跟业务真的一点都不搭界。
第二个问题作者认为如果谁都可以调用，那么最后这个服务也要考虑向前兼容性。对此我没有什么异议。
一个好的大型系统的设计，一定是当需要做迭代和改动的时候，很容易判断和知道应该在哪一个环节做修改。
这个也是服务化带来的价值，而进一步微服务化，往往非常容易破坏这一点。
我还是有两个疑问：1. 怎样区分服务化和微服务化（这个问题从一开始就存在）；2. 为什么微服务化反而不容易判断需要修改的环节？
回到微服务，在我看来，他并没有解决软件开发的“控制复杂性”这个核心问题。而只是在尝试不停地“转移复杂性”，并且在这个过程中，非常容易“增加复杂性”。
微服务真的只是在“转移复杂性”吗？如果换成“分解复杂性”是不是更贴切。但微服务是“转移复杂性”还是“分解复杂性”，真的就人嘴两张皮，反正都是理。
真正适合用微服务的场景非常少，要么就是巨头的核心业务，要堆上几百几千人研发团队的情况。
我对此没有什么异议。