微服务

微服务是 SOA 的一种实现

SOA 是面向服务的架构，微服务也是面向服务架构的一种实现。如果引用微服务领域的先驱 Martin Fowler 的话，那么“我们应该把 SOA 看作微服务的超集”。微服务是 SOA 的一种敏捷实现，之前 ESB 是 IBM 对 SOA 一种不太完美的实现，在微服务这个概念被 Martin Fowler 大神创造出来之前，阿里巴巴使用 Dubbo、HSF 实现了自己的微服务体系，其实也是 SOA 的一种实现。

 

微服务解决的本质问题是团队分工

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

 

你有几个 2 pizza 团队，最好就拆成几个微服务。举一个现实的例子：只有一个开发人员时，尽量就做单体应用，不要没事找刺激拆成 10 个微服务，最终这个开发人员还会把他合成一个。微服务要求纵向的 2 pizza 团队（无数个小团队，包含开发、测试、运维），当然我们也实施过一些传统大型企业，但团队还是处在横向结构的场景下（开发、运维、测试各是一个团队），拆分微服务让他们很痛苦，尤其是运维团队。

 

微服务带来挑战是分布式下开发、测试与运维的复杂性

永远不会有银弹，但是我们要接受历史的潮流，并且适应它。微服务的出现解决了团队分工问题，同时也会引入新的问题，但是并不是“基础设施的庞大复杂”。

 

EDAS 其实已经提供了大部分“基础设施”。微服务跟开车一样，车（基础设施）我们可以不去造，但是学会开车（微服务理念）是对单体应用开发、测试与运维最大的挑战。例如：单体应用开发者从来不会去想方法调用会失败、会重试、要幂等；单体应用测试人员不会去想几十个应用我怎么一起集成测试；单体运维人员不会去想下游应用挂了对我有什么影响。意识到分布式下开发、测试与运维的复杂性，并掌握解决这些复杂问题的方法，才是更主要的。

 

微服务至少还能活 18 年

当然不能因为微服务存在问题，我们就说它将死。很多人说 Java 将死，从 2000 年就听说过这个论调，18 年过去了 Java 还活着，而且最近还搞得风生水起。

 

谈到微服务将死，那么这里联系一下 Java，我认为微服务至少还要活 18 年，并且它也值得我做一辈子，我们会提供完善的基础设施（车），提供完善的最佳实践（教练），帮助开发者享受微服务（开车）带来的好处。

 

下一代架构是 Serverless

此处提到的 Serverless != FaaS，Serverless 包含底层中间件的 Serverless 及服务本身 Serverless，而 FaaS 只是其中一种比较简单的实现。那篇文章中提到的 Flink 跟 FaaS 实际上并无本质区别，但是本身商业化比 FaaS 差得比较大。

来自：https://mp.weixin.qq.com/s/jArp9LUnLv9jveh9qTndfA。

 

 

康威定律

出乎很多人意料，微服务很多核心理念在半个世纪前（1968年）的《How Do Committees Invent?》一文中就被阐述过了，这篇文章中的很多论点在软件开发飞速发展的这半个世纪中竟然一再被验证，这就是康威定律（Conway's Law）

有意思的是该论点在提出多年后一直默默无名，后来Brooks Law著名的人月神话引用这个论点，“康威定律” 从此进入大众视野。

二、康威定律

wikipedia显示，康威定律（http://www.melconway.com/Home/Committees_Paper.html）最著名的一句话这这样的

 

“organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.”

大致的意思是：系统设计(产品结构)等同组织形式，每个设计系统的组织，其产生的设计等同于组织之间的沟通结构（简单点说就是，系统的设计受限于设计系统的组织的人员架构形式。我们也经常说微服务不光是一个技术问题，更是一个研发组织问题）

想一想你用过的产品，看一看下边这张图，也许能加深对康威定律的理解 

 

Mike Amundsen （Design RESTful API的作者），在《远距离条件下的康威定律——分布式世界中实现团队构建》的一次技术分享中，从他的角度归纳这篇论文（《How Do Committees Invent?》）中的其他一些核心观点

1、Communication dictates design（组织沟通方式会通过系统设计表达出来）

2、There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做的完美，但总有时间做完一件事情）

3、There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）

4、The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）

Mike Amundsen的更多细节不展开了，感兴趣可以自行搜索。

三、支持康威定律的证据

wikipedia在康威定律条目的Supporting evidence章节有如下描述。

麻省理工学院和哈佛商学院研究小组发表了支持康威定律的证据，他们使用“镜像假设”作为康威定律的等效术语，发现“支持镜像假设”的有力证据，“[产品]模块化的显着差异”与“分布式团队倾向于开发更多模块化产品的观点一致”。

马里兰大学的Nagappan、Murphy和Basili与微软合作，以及芬兰坦佩雷理工大学的Syeed和Hammouda的案例研究，同样支持康威定律。

四、康威定律如何解释微服务的合理性

了解了康威定律是什么，再来看看他如何在半个世纪前就奠定了微服务架构的理论基础。

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

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

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

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

带来的具体的实践建议是

• 我们要用一切手段提升沟通效率，比如slack，github，wiki。能2个人讲清楚的事情，就不要拉更多人，每个人每个系统都有明确的分工，出了问题知道马上找谁，避免踢皮球的问题。

• 通过MVP的方式来设计系统，通过不断的迭代来验证优化，系统应该是弹性设计的。

• 你想要什么样的系统设计，就架构什么样的团队，能扁平化就扁平化。最好按业务来划分团队，这样能让团队自然的自治内聚，明确的业务边界会减少和外部的沟通成本，每个小团队都对自己的模块的整个生命周期负责，没有边界不清，没有无效的扯皮，inter-operate, not integrate。

• 做小而美的团队，人多会带来沟通的成本，让效率下降。亚马逊的Bezos有个逗趣的比喻，如果2个披萨不够一个团队吃的，那么这个团队就太大了。事实上一般一个互联网公司小产品的团队差不多就是7，8人左右。

公司级的组织结构设置看起来层次很高，回到最初的问题，你的小团队微服务到底拆分多少合适呢？

《How Do Committees Invent?》文中提到任务的拆解可以嵌套进行，意思是先按照大力度拆，拆分出的部分继续按照更细的粒度拆分，直到不需要拆分为止。

结合阿里姬望和我个人的经验。如果你还是新手，那么你预期项目有几个人开发就拆成几个部分一般不会有大的问题；如果你比较有经验，可以结合公司微服务的治理能力灵活发挥。

标签：SOA,服务,康威,运维,定律,第一篇,团队
来源： https://www.cnblogs.com/microsoft-zyl/p/10460788.html