10.微服务设计 --- 康威定律和系统设计

 

康威定律和系统设计　
	康威定律：
		任何组织在设计一套系统时，所交付的设计方案再结构上都与该组织的沟通结构保持一致。　
1.证据　　
	1.1　松耦合组织和紧耦合组织　　
		松耦合组合和紧耦合组织。紧耦合组织的一个例子是商业产品公司，他们的员工都一起工作，并有着一致的愿景和目标；而松耦合组织的典型代表是分布式
	  开源社区。组织的耦合度越低，其创建的系统的模块化就越好，耦合也低；组织的耦合度越高，其创建的系统的模块化也越差。
	1.2 Windows Vista
	　　
2.Netflix和Amazon　　
	两个披萨团队：没有一个团队应该大到两个披萨不够吃。

3.我们可以做什么　　

4.适应沟通途径　
	　一个简单的团队可以进行频繁，细粒度的沟通。服务内部是大量细粒度的方法和函数调用。服务内的变化的频度远远高于服务间的变化。
	  物理位置不在一起的团队，只能依靠粗粒度的沟通。 

5.服务所有权　　
	服务所有权：它意味着拥有服务的团队负责对该服务进行更改。只要更改不破坏服务的消费者，团队就可以随时重新组织代码。把决定权交给合适的人，赋予团队更多
  的权利和自治。

6.共享服务的原因　　
	6.1.难以分割　
		拆分服务的成本太高是多个团第负责单个服务的原因之一。　
	6.2.特性团队　　
		一个小团队负责开发一系列特性需要的所有功能。这种结构促使团队保持关注在最终结果上，并确保工作是集成起来的，避免了跨多个不同的团队视图协调变化的挑战。
	  在许多情况下，特性团队是对传统的IT组织中，团队结构围绕技术边界进行组织的一种修正。
	    什么是微服务：服务会根据业务领域，而不是技术进行建模。如果负责某个微服务的团队与业务领域相匹配，则它更容易保持对客户的关注，也更容易进行以特性为导向
	  的开发，因为它对服务相关的所有技术有一个全面的了解并有用所有权。
	6.3.交付瓶颈
		共享服务的另外一个关键是，这样做可以避免交付瓶颈。不共享服务，我们有几种方式来应对。第一种是等待。另外一种是，你可以派人到缺人的团队工作。　　

7.内部开源　
	如果我们已经尽了最大的努力，仍然无法找到方法来避免共享几个服务该怎么办？这个时候，拥抱内部开源模式可能更合理。
	标准的开源项目中，一小部分被认为是核心提交者，他们是代码的守护者。
	　
	7.1　守护者的角色　
		我们在内部也要采用跟标准开源项目同样的模式。这需要分离出一组受信任的提交者(核心团队)和不受信任的提交者(团队外提交变更的人)。核心团队需要对更改拥有
	  某种审批，它需要确保所有的更改符合该代码库的惯例。
	7.2　成熟　　
		大多数开源项目在完成第一个版本的核心代码前，往往不允许让更广泛的不受信任的提交者们提交代码。
	7.3　工具　
	　
8.限界上下文和团队结构　　
	我们以限界上下文来定义服务的边界。因此，我们希望团队也跟限界上下文保持一致。这有很多好处，首先，团队会发现它在限界上下文更容易掌握领域的概念，因为它们是
  互相关联的。其次，限界上下文中的服务更有可能发生交互，保持一致可以简化系统设计和发布的协调工作。最后，在交付团队与业务干系人进行交互方面，它有利于团队与此
  领域内的一两个专家创建良好的合作关系。

9.孤儿服务　
	那么如何处理不再活跃维护的服务呢？当我们迈向更细粒度的架构时，服务本身变得更小。小服务的目标之一是使它们更简单，功能较少的简单服务，可能在很长的一段时间内
  都不需要修改。
  　
10.案例研究：RealEstate.com.au　　
11.反向的康威定律　　
12.人