微服务，肯定不是创建好多的服务就可以了，在build和deploy上也应该可以各个服务自己决定何时去build，何时去deploy，这种发布上的灵活性，我认为是微服务的最大好处。
可是我们现在的微服务，虽然有了好些个服务，可是在build和deploy上还必须绑在一起。build是全部在一起build，deploy也是得好几个服务一起deploy。
那么问题在哪里呢，问题就在于代码级的共享。比如好几个服务都公用一个library。
亚马逊的微服务设计原则中有一条：所有的服务，只依赖于其他服务的API接口，除此之外没有任何代码级的依赖。
那么亚马逊为什么要定这么一个规则呢，就因为如果你这个公用的library要是有什么修改，那么是不是所有的服务都得跟着一起改，一起改完是不是还得一起deploy，所以代码级的依赖彻底破坏了微服务的自治性。
那么好几个服务都依赖一些公用的功能，这也是非常常见的，怎么解决这个问题呢，一种想法是把这个library做成可发布的包，比如nuget。但这种想法其实也解决不了问题，比如服务A依赖这个包的1.0版本，服务B依赖这个包的1.1版本，那么开发者是不是要维护这个包的所有版本的code呢？这个代价就大了。
那么唯一的做法只能是把这些公用的功能也变成微服务。可以提供不同版本的API，这样尽管也是不同版本，但是至少可以尽可能复用一份code，而上面那种打包技术是无法做到复用code的。
另一种办法也可以是，如果这个公共库不复杂的话，就把它的code duplicate到每个服务自己的code里面去，然后每个服务自己想怎么改就怎么改了。不过这样要考虑code duplicate造成的不同微服务的开发者都得阅读理解这些code的时间成本开销和上一种做法之间的cost大小的比较取舍。
那么亚马逊的贝索斯还说过：团队的规模要尽可能小，不要超过2个披萨管饱。
那么这个2个披萨团队的概念，难道不正是为了match微服务开发的需要而产生的吗。
微服务是不是也足够小，一个几人小团队match一个微服务，团队之间只有API依赖，团队内部自洽，是不是很nice。
但是这就要求每个小团队都必须是全栈的，至少如果是写服务的话，从backend到data到devops，这个团队需要全都有人能干，最好还能干点UI，以防自己的服务和外面UI对接。
然而，我们现在的组织架构，是按照function unit的划分，写UI的一个team，backend一个team，devops一个team，data一个team。这天然的和上面的全栈小团队要求是相违背的。根据康威定律，什么样的组织架构就能产生什么样的产品边界。
《赋能》一书中说，对于现代企业来说，能适应变化的重要性要高于提升那么一点工作效率。此书中举出的具有冗余性的团队的例子，其实和上面的自治小团队完全一致。
总体来讲，我觉得微服务带来巨大好处的同时也带来了巨大的困难，对人员的技术能力要求也很高，我们离真正的微服务还有点距离。