如果你在众多流行的云计算技术中找到最热门的方向，比如容器、微服务、DevOps等，微服务非此莫属。此外，诞生了几十年的康威定律在组织架构调整和改革方面依然如火如荼。创建一个新的软件项目架构来封装离散服务对于全新的项目来说非常简单。然而，对于大多数软件开发人员来说，谁有闲暇时间一直花在全新的项目上呢？大多数软件开发人员更负责维护或向现有软件系统添加功能。但如果问开发者是愿意建立一个全新的项目还是维护现有的系统，对新项目的呼声肯定会变得铺天盖地。事实上，与新技术或新项目合作的愿望也是开发人员离职的原因之一。为什么？1、发现问题容易，解决问题难。维护现有系统时，很容易发现架构问题。为什么？因为它基于一个好的架构，所以系统很容易调整。在没有设计封装波动的情况下调整现有系统时，架构的弱点是不言而喻的。即使是最小的表面变化也会对系统的其余部分产生复杂的涟漪：似乎无限期存在的新依赖关系，膨胀的方法签名获得更多参数，自动化测试的规模和复杂性爆炸，同时降低实用性。这些问题听起来是不是很熟悉？你的企业结构是这样的吗？如果答案是肯定的，那么你就有了一个单体架构。单体架构是大多数软件开发人员遇到的最常见的架构。这种单体架构来自根本不是为了封装波动而设计的系统，而是随着业务需求和时间变得越来越复杂。那么如何处理单体架构呢？在单体架构中工作时，每个人都会受苦，开发人员和业务人员也是如此。开发者讨厌臃肿的单体架构，因为开发的难度会随着新的开发活动的增加而增加。一旦单体达到临界质量，它如何改变就会成为一个真正可怕的挑战。这会导致生产力和团队士气降低，业务也会受到影响。企业需要快速行动，而单体架构会随着时间的推移变得越来越慢。很多开发者想扔掉现有的架构，重新来过，但是这种想法无法随着业务的发展而增长。“最好的软件是目前让公司赚钱的软件，不管新版本多牛！”因此，新方案不能完全抛弃旧的单体架构。业务必须继续，但不会再添加单体。架构复杂性。微服务？微服务是一个流行的术语，它模糊地表达了一种由许多小的离散服务组成的面向服务的架构。从表面上看，微服务似乎是单体架构的对立面（每个人都讨厌单体架构），许多微服务通过提出新的功能请求而表现为独立的服务。这就是问题所在：虽然单体架构封装了系统的所有易变性，但分离独立服务并不能使企业免受任何易变性的影响。这是一个用微服务实现的单一功能架构，它看起来像这样：单体变小了一点，新功能明显与系统的其余部分分离。这个好吗？当下一个功能请求出现时会发生什么？对于两个函数，我们看到了一个问题。第二个功能建立在第一个功能之上，因此不能完全隔离。如果只是在收到功能请求时创建新的微服务，而不是封装整个波动区域：是否有改进？看看原始单体应用程序旁边的微服务：如果仔细观察，所有服务依赖线都模糊在一起，这只是发明了一个更复杂的单体架构。小的变化仍然会在整个系统中产生复杂的涟漪。改变整个系统的行为将涉及改变多个微服务。所有相同的问题再次出现，甚至可能更糟，因为依赖关系很难追踪，而且计划周密的多服务部署比庞大的单体应用程序更可怕。什么地方出了错？问题源于微服务本身不是架构这一事实。微服务只是一个描述作为独立服务运行的系统的词，而不是一个单一的应用程序。软件架构的实践包括仔细规划在离散服务之间划分边界的位置，从而包含波动区域。当单纯的拿一个单体应用作为一个独立的服务来实现时，不需要考虑整个系统的封装波动。只有把系统作为一个整体来考虑，才能谈架构。因此，如果单体应用和功能驱动的微服务太小，我们应该如何处理呢？要知道你想去哪里就是为整个系统设计理想的架构，就像你从头开始创建它一样。企业不可能直接从单体架构走向微服务架构，但是如果第一次启动的时候不知道自己想要达到的方向，那是永远也走不过去的。对任何希望拆分现有单体应用程序的软件开发人员的一些建议，但现实是该路线图对于每个系统都是独一无二的。Tips如果只设计新的功能而忽略现有的单体应用，是无法打造出优秀的架构的；如果不考虑整个系统，单体应用无法有效分解；微服务只是一个流行语。越小并不总是越好。仔细划分服务边界很重要；2.微服务和团队：康威定律微服务架构的独特之处在于它们随着时间的推移保持灵活性，并不断影响项目的组织结构。对于大多数公司来说，这是非常具有挑战性的，因为它需要企业重新考虑组织模型。在准备上手微服务架构时，可以先问问自己：“企业的组织能力如何？”前期，前提应该是对遇到的困难提前做好准备，想好对策。微服务和康威定律：企业需要与团队合作的架构在组织团队和微服务时，经常会提到著名的康威定律。这条法律越来越被广泛接受。这个规律的缺陷在于它更像是一个社会学规律而不是一个纯粹的科学规律。事实上，它总是通过论证和实例来证明，而不是纯粹的科学逻辑。总的来说，社会学的结果很难证明，因为这些论证很大程度上是基于假设性的思维和概念，只能通过更多的例子来验证。“组织的系统设计……通常受到组织结构的产品设计和通信副本的限制。”从这个规律中，可以得出一些简单的结论：如果你想要一个特定的结构，你需要一个与组织团队合作的结构。架构变动频繁，组织团队也需要经常修改。这两个断言对康威定律的原理具有深远的影响。首先是企业的适应性，避免了野心勃勃、抗拒变革等倾向，也引发了机器代替人力的哲学思考。基于以上结论，关于微服务架构首先要问的问题是：“组织团队如何适配这种架构？”Netflix和亚马逊的情况当然非常乐观，但是您的企业准备好了吗？最重要的是通过挖掘技巧和发现问题时的“刹车”措施来规避风险。其中的技巧可以快速提升团队的能力。创建功能时，负责其实现的团队汇集了许多不同的技术。当架构进入微服务模式时，将出现更多的协调需求。另一个技巧是开源技术的治理模型。开源项目，由于其分散的结构，使得创建高度松散耦合的软件成为可能，这是微服务架构的优势之一。因此，它成为一种与其他团队协作并推动具有代码能力的小团队实施代码更改的方式。但这种逻辑和组织变革在公司中的可接受度如何？这些技能是否足以在整个公司内协调、积累经验和知识？去中心化组织构建松散耦合的代码，但技术或功能知识和技能不能极端解耦。否则，就像拆东墙补西墙，用拆掉的墙来搭建一个松散耦合的架构。真正的僵局将在于文化和管理方式，这在最近几年有所改善。一个很好的例子是Spotify的框架（尽管我们应该将自己限制在元框架上，因为我不会在这里讨论的原因）。Spotify使用开源组件来构建功能和治理，使用这些工具大规模实现灵活性矩阵模型。矩阵组织必须确保知道不同的人拥有什么知识或技能。最近流行的新管理方法开始产生影响，尤其是在那些希望实施微服务的团队组织中。合弄制管理模式：在满足商业模式的前提下，完成微服务的实践***以上提到的企业文化、主体、变革阻力。第一类管理源于合弄制管理模式。合弄制分为自治和独立，并链接到比自己更高的实体。这些圈子可以以闭环的形式相互重叠，具有自组织和上层管理的特殊性。每个圆圈对性质和构图的变化都非常敏感。可以想象，比如最底层的圈子是微服务的开发团队，而上层是架构和产品的负责人，最上面是应用的客户业务线。这将使产品和架构负责人能够在满足业务需求的前提下确保架构的最佳实践。这种架构方法也是开发人员和软件架构师的典型方法。所有这些都可能来自不同或重叠的圈子。建立这种类型的组织是为了提高知识传递和构建架构的时间效率。我们可能会认为这种管理更符合传统的等级组织。事实上，即使层次结构是扁平的，它仍然存在并且可以约束它的项目团队。总之，最好的办法就是简化人与人之间的联系。
