关于康威定律的思考

Posted 2021-04-24 海科融通技术团队

在上一篇的文章中，曾提到过康威定律的第一定律。看一看工作中出现的问题，功能使用者边界不清晰，互相踢皮球，在系统层面，出现系统问题永远是那么固定的几个救火队员，架构的腐化眼睁睁的在进行，服务的边界逐渐模糊，重复代码到处蔓延，曾经简单的服务正在向一个大而全的单体应用在演进，是我们的管理问题，流程问题，规范问题，时间问题，需求问题，还是其他等等的客观问题导致的吗？或许大家讨论起来都能扯上一些关系，不禁让我对系统重新思考，一定有一个关键的因素导致了现在的状况，我得出了一了一个结论，那就是我们的系统架构一部分偏离了康威定律，虽然说微服务的架构逃离不了康威定律，岁月的变迁是任何人无法阻挡的自然规律，软件工程是计算机科学的一部分，也是人类自然活动的一部分，自然也无法违背时代发展的定律。今日的果一定是昨日的因引起的。

我们再来重读一下康威定律的原文：

大致的意思是：系统设计(产品结构)等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构，简单的说：系统的设计受限于设计系统的组织的人员的架构形式。

所以微服务不光是一个技术问题，也是一个研发组织的问题。了解了康威定律是什么，再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

人与人的沟通是非常复杂的，一个人的沟通精力是有限的，所以当问题太复杂需要很多人解决的时候，我们需要做拆分组织来达成对沟通效率的管理。

组织内人与人的沟通方式决定了他们参与的系统设计，管理者可以通过不同的拆分方式带来不同的团队间沟通方式，从而影响系统设计。

如果子系统是内聚的，和外部的沟通边界是明确的，能降低沟通成本，对应的设计也会更合理高效

复杂的系统需要通过容错弹性的方式持续优化，不要指望一个大而全的设计或架构，好的架构和设计都是慢慢迭代出来的。

一个有过2年以上开发经验的研发人员，一定能有这样的体会，我们期望中理想的需求变更永远那么遥远，现实中总是需求总是变来变去，任何理论的开发模型在实际的工作中落差总是那么大。其实做业务开发工程师应该能意识到业务的一个显著特点，那就是复杂性与多变性。对于业务驱动的公司来说，任何技术都是要为业务服务的，引用前几年网络上的一句话：“任何不以结婚为目的的谈恋爱都是耍流氓”。套用到我们的研发工作中就是：“任何不以业务为目标的技术都是无价值的”。有人可能说这么说过于概论，但中国的软件行业绝大部分工程师都是业务开发工程师。纯粹的以技术驱动的公司少之又少。所以业务的这个特点也就决定了理想与现实的差距。

回过头来，我们再结合我们的系统架构，看看我们到底哪部分偏离的康威定律。拿一个真实的场景看一下，我们的支付平台分渠道和直营，对于组织结构呢，前端市场是分离的，产品，运营，财务，研发，又是横向的。回想我们之前的组织架构，事业部制的形式，每个是事业部有自己独立产品，研发，运维，运营。当多个事业部的时候，都有自己独立的系统。需求明确，规则明确，迭代速度也快。虽然是单体应用，但效率也不低。但产生的后果也很明显，资源的重复，系统的孤立，数据的孤岛。对于公司而言是另一种问题。在三国演义的开篇，曾说过天下大势，分久必合，合久比分。大势尚且如此，我们一个小小的软件工程自然也逃不开这个规律。看看我们的产品，系统，不正是在这样的规律下发展吗？

曾经的新平台做的是合，现在的新营销模式，还有其他的等，现在做的是分。这是无法阻挡的趋势，因为这是时势所趋。那么我们的微服务架构又该怎样的演进呢？我们服务粒度拆分的是否合理呢？我们业务连续性如何的保证呢？我们的扩展性如何更有弹性呢？这些问题对于我们再做系统设计与开发的时候要如何考虑呢？问题的根源其实已经给了我们实施的理论基础。也就是康威定律。

微服务解决的本质问题是团队分工，SOA也好、微服务也好，解决的根本问题是团队分工问题，这是大型软件发展的必然，不因为人的喜好而改变。当你读懂康威定律，就会发现“服务拆分粒度难以准确把握”根本不是本质问题。

曾经总结过我们收单业务的3大主线：交易结算，入网，营销.我们始终在围绕这三大主线在开发系统。简单的分成3个服务，显然过于庞大，所以我们需要再进行细粒度的拆分。随着研发人员的增加，服务的增加，维护成本成指数级增长，在加上曾经的技术债务未能及时偿还，也就造就了在文章开头我们所出现的问题。所以现在该做的是分离。大服务拆小服务，大主线拆成多个小主线。服务的功能要尽可能的单一，哪怕是只提供查询的功能也可以独立成一个服务，对于业务连续性要求比较高的线路，由独立的服务组进行编排组织。由大化小，化繁为简。带入我们的工作团队来看，我们进行了研发组的划分，自然遵循的康威定律就很好解释我们如何对微服务粒度的控制了。