微服务与康威定律：企业须要与团队协同的架构
建立一种新的软件项目架构，来封装离散服务，对于全新的项目来讲，这是很是简单的。可是，对于大多数软件开发者来讲，谁又有大把的奢侈时间一直用在全新项目上呢？api
大多数软件开发人员职责更可能是维护或增长现有软件系统的功能。可是，若是问开发人员到底是愿意构建全新的项目，仍是维护一个现有的系统，那么支持新项目的呼声确定会成为压倒性的声音。事实上，但愿与新技术或新项目合做也是开发人员离职的缘由之一。为何呢？架构
1. 识别问题容易，但修复很难
维护现有系统时，很容易识别架构的问题。为何？由于基于良好的架构，系统很容易调整。app
当须要去调整一个没有设计封装波动的已有系统时，架构的弱点就不言自明。即便是最小的表层变化也会给整个系统的其余部分带来复杂的涟漪：新的依赖看似要无止境地延续下去，经过臃肿的方法签名得到更多的参数，自动化测试的规模和复杂性爆炸，同时下降了实际效用。框架
这些问题是否是听起来很熟悉？你企业的架构是这样的吗？微服务
若是答案是确定的，那么你有一个单体架构。单体架构是大多数软件开发者遇到的最多见架构。工具
这个单体架构来自那些根本没有设计封装波动的系统，可是随着业务需求和时间的推移，变得愈来愈复杂。测试
那么用单体架构作什么呢？ui
每一个人在单体架构中工做时都会感到痛苦，开发和业务人员也是如此。开发者讨厌臃肿的单体架构，由于开发的难度会随着新开发动做的增长而增长。一旦单体架构达到临界值，如何改变会成为一个真正可怕的命题。这会致使生产力和团队士气降低，业务受到影响。企业须要快速行动，单体架构却会随着时间的推移而变得愈来愈慢。spa
许多开发人员都但愿把已有的架构丢掉，从新开始，可是这种想法没法和业务一块儿成长。“最好的软件是目前就让企业赚钱的软件，不管设想中的新版本多么伟大！”.net
因此新的计划不能彻底抛弃旧有的单体架构，业务要继续，但不会再增长单体架构的复杂度。
微服务？
微服务是一个流行的词汇，它模糊地表达了一个面向服务的架构，其中包含许多小的离散服务。
从表面上看，微服务彷佛是单体架构的对立面（每一个人都讨厌单体架构），许多微服务经过提出新的特性请求，并以独立服务的形式出现。这里的问题是：当单体架构封装全部系统的波动性，解耦的独立服务并不能使企业免于任何波动。
如下是用微服务实现单个功能架构，它大概像这个样子：
单体应用变得小了一点，新功能清晰地从系统的其他部分解耦。这很好吗？
当下一个功能请求进入时会发生什么？
有两个功能，咱们已经看到一个问题。第二个功能创建在第一个功能之上，因此不能彻底隔离。
若是随着功能请求的进入，简单地建立新的微服务，而不是封装整个波动区域：
有改善吗？来看看原始单体应用旁边的微服务：
若是仔细观察，会发现，全部服务依赖线模糊在一块儿，这只是发明了一个更复杂的单体架构。
小小的改变在整个系统中仍然会带来复杂的涟漪。整个系统的行为改变将涉及到改变多个微服务。全部相同的问题再次出现，甚至可能更糟糕，这加重了依赖关系难以追踪的事实，并且，精心策划的多服务部署比庞大的单体应用更加可怕。
什么地方出了错？
问题源于微服务自己不是架构。微服务就是一个简单的词，描述了做为独立服务运行的系统，而不是一个单体应用。软件架构的实际实践包括仔细规划，在哪里划分离散服务之间的界限，从而包含波动区域。当简单地拿出一个单体应用，做为独立服务来实施时，就没有必要来考虑整个系统的封装波动。
把系统看做一个总体，才能谈架构
所以，若是单体应用，功能驱动的微服务过小，该怎么作应对？
要知道想去的方向
要像从头开始建立同样，为整个系统设计理想的架构。
企业不能一会儿从一个单体架构直接进入微服务架构，可是若是第一次启动的时候，不清楚想达成的方向，那么永远也不会到达那里。
给全部但愿拆分现有单体应用的软件开发者提供一些建议，但实际状况是这个路线图对于每一个系统都是独一无二的。
Tips
若是只是设计新的功能而忽略已有的单体应用，则没法建立出色的架构；
若是不考虑整个系统，单体应用就不能有效分解；
微服务只是一个流行词。更小并不老是更好。精心拆分服务边界很重要；
2. 微服务与团队：康威定律
微服务架构是独特的，随着时间的推移仍然保持灵活性，在一个项目的组织架构中时时发生影响 。对于大多公司而言，这很是具备挑战性，由于它要求企业从新考虑组织模式。当准备开始微服务架构时，能够先问本身：“企业的组织能力是什么？“在早期，先决条件应该是预先准备会遇到的困难，并思考应对之策。
微服务与康威定律：企业须要与团队协同的架构
当涉及到组织团队和微服务，著名的康威定律常常被提到。这项定律，愈来愈被普遍地接受。
这必定律的缺陷在于，它更可能是一种社会学规律，而不是纯粹的科学规律，事实上，它老是以实证、实例的方式，而不是纯粹的科学逻辑来论证。通常来讲，社会学的结果很难证实，由于这些论证很大程度上基于假想中的思考和概念，只能经过更多的实例来加以验证。
“组织的系统设计…每每受限于组织架构的产品设计和通讯的副本。”从这个规律，能够得出一些简单的结论：
若是想要特定的结构，须要一个与组织团队协同的架构。
若是常常改变架构，组织团队也须要常常修改。
这两个断言，对于康威定律的原则，有着深远的影响。首先是一个企业的适应能力，避免了野心家的倾向，对变革的抵制等等，也引起了机器取代人力的哲学思考。
基于以上结论，要上微服务架构的第一个问题是：“组织团队如何适应这种架构?” Netflix 和亚马逊的状况，固然是很正向的，可是否你的企业是否准备好了？其中重要的是，挖掘技巧和发现问题时的“刹车”措施来规避风险。
其中的技巧能迅速提高团队的能力。在建立一个功能时，负责功能实现的团队聚集了不少不一样的技巧。当架构进入微服务模式时，将出现更多的协调性需求。
另外一个窍门是开源技术的治理模式。开源项目因为其分散的结构，使它可以建立高度松耦合的软件，这是微服务架构的优势之一。它所以成为与其余团队的协做方式，并推进具备代码能力的小团队，在代码中实现变化。
可是，这个逻辑和组织变革在公司的接受度如何？这些技巧是否足够在全公司范围内协调、积累经验和知识？分散的组织构建松耦合的代码，但技术或功能性的知识和技能不可能极端的解耦。不然，这就像拆东墙补西墙，是在用拆掉的墙来构建松耦合的架构。
真正的僵局会出如今文化和管理风格上，这点在最近几年有了好转。
一个比较好的例子是Spotify的框架（虽然咱们应该限制本身使用meta frameworks，缘由再也不赘述）。Spotify采用经过使用开源组件来架构功能和治理，使用这些工具在必定规模下实现了灵活性矩阵模型。矩阵式组织必须确保知晓不一样人具有的知识或技能。
最近流行的新管理方法已初见影响，特别是在那些寻求实现微服务的团队组织中。
Holacracy管理模式：知足业务模式前提下，完成微服务最佳实践
上面谈到了企业文化、主体、和变革的阻力。第一种类型的管理，来源于 Holacracy 管理模式。
Holacracy分为自治和独立，并连接比本身更高的实体。这些圈子以闭环的形式，能够互相重叠，具备自组织而被上层管理的特殊性。每一个圈子对于性质和组成的变化很是敏感。
能够想象，例如，底层圈子是微服务的开发队伍，而上一层是架构和产品负责人，最顶端是应用的客户业务线。这将让产品和架构负责人要能在知足业务需求的前提下，才能保证架构的最佳实践。
这种架构方式也是开发者、软件架构师的典型方式。全部可能来自不一样或重叠的圈子组织。创建这种类型的组织是为了提升知识传输和构建架构的时间效率。
咱们可能会认为，这种管理比较符合传统的层级组织。
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------