Author: haoransun
Wechat: SHR—97
参考
https://www.martinfowler.com/articles/microservices.html
https://martinfowler.cn/
ps: 图片使用 ProcessOn 或者 百度脑图
学习来源：极客时间-微服务架构核心20讲，本人购买课程后依据视频讲解汇总成个人见解。
1. 什么是微服务架构
关键人物：技术大牛马丁-福勒与前Netflix技术总监阿德里安·克罗夫特。
马丁-福勒在自己的博文中介绍了微服务架构，其中微服务架构的关键点如上图所示。
阿德里安·克罗夫特见证了网飞架构由单块演化到微服务，在这之后，给服务下了一个比较抽象的定义。
Loosely Coupled
服务之间应该是松散耦合，不是强依赖的，每个团队在开发自己的服务时，如果过度依赖其他团队的服务，开发人员没有办法简单的忽略周边的服务，这就不能认为是松散耦合的。Service Oriented Architecture
服务面向架构，本质上还是一个SOA，只是更细化，更落地。With Bounded Context
有界上下文，即局部状态。每个团队有自己维护的数据源，独立的去演化自己的模块，对业务的支持更便捷。
思考
独立部署给业务带来了什么样的好处呢？
分布式系统中，每个团队有自己独立的数据源，会带来一些什么样的挑战呢？
2. 架构师如何权衡微服务的利弊
架构师最重要的能力时权衡。
1. 利
强模块化边界
做软件架构、软件设计，模块化是一个很重要的方面，刚开始写代码时，用类的方式做模块化，后面开始用组件、类库的方式做模块化，可以重用，分享给其他团队来使用，微服务又高了一层，以服务的方式来做模块化，每个团队独立开发维护自己的服务，有一个清晰的边界；其他团队就可以去调用这个服务，不需要像jar包一样去引入，边界比较清晰。可独立部署
与传统单块服务不同，微服务可独立部署，每个团队根据自己的需要，当业务方或产品经理将需求提过来后，可以独立的开发、独立的部署。一般情况下，不需要involve其他很多的团队进行协同，单块应用程序就需要很多的团队来帮忙做集成测试，可降低协同开销。技术多样性
微服务是分散式治理，每个团队根据自己的实际情况、业务需求来选择最优的技术栈，比方说有的团队擅长用Java语言开发服务，有的团队更偏向前端，擅长用NodeJS开发服务，当然技术栈不是越多越好，技术栈的引入也是有成本的。
2. 弊
分布式复杂性
单块应用，基本上一个团队就能搞定，一个开发人员都可对架构有很好的把控，微服务化后，涉及的系统可能有好几十个，在一些大的公司，甚至可能上百个，服务之间相互沟通合作实现业务功能，系统极为复杂，一般的开发人员或团队没有办法非常清晰的理解整个系统是如何工作的。最终一致性
数据也是分散治理的，每个团队都拥有自己的数据拷贝，比如说订单数据，A团队可能有订单数据，B团队也可能有订单数据，当A团队改了这个订单数据后，相关的信息需要同步到其他依赖这个数据的团队，这就会引入数据一致性问题，如果数据不一致，在业务上是不可接受的。运维复杂性
分布式系统需要很多的服务，相互之间协同，对运维来说，他需要管理、运维的是一个分布式系统，对监控、容量规划、系统的可靠性、稳定性提出了非常大的挑战。测试复杂性
单块应用只需要测试团队去完整的测试单块应用就Ok，而分布式系统，这些系统是分散在各个团队的，对测试的要求极高，需要很多团队一起来联合做集成测试，即所谓的联调，测试复杂性非常高。
3. 思考
运维团队在面对微服务架构时，应该采用一些什么样的手段来应对这样级别的复杂性呢？
3. 康威法则和微服务给架构师怎么样的启示
参考：https://yq.aliyun.com/articles/8611
康威法则是由一个叫康威的人1967年提出来的（这不是废话吗？），他原来是一个程序员…后来搞起了外卖，纯粹是开玩笑啦。他的原话是这样讲的。
设计系统的组织，其产生的设计和架构等价于组织的组织架构。
康威法则被认为是微服务的理论基础，为什么这样说呢？这里讨论下康威法则与微服务之间的关系
一个互联网公司刚开始起步的时候，业务量不是很大，是去尝试自己的业务模式能否起来，所以一开始开发的系统一定是一个简单的、单块的系统，这个时候团队规模也不是很大，一般就几个人定。
随着它的业务量越来越大，它的团队规模也会变大，原来的一个团队可能不够了，需要两个、三个甚至而更多的几十个团队来协同，这个时候，如果系统架构仍然是单块的，他就跟分散式的、多团队之间产生了一种不匹配的情况，违反了康威法则，单块应用架构没有反映组织的组织架构。此时就会出现矛盾，沟通、协调成本很高，交付效率很低，且易容易产生摩擦。如何解决这个问题呢？
微服务是解决此类问题的一个手段，将单块的应用拆解出来，拆分成若干个微服务，比如说组织内部有3个团队，就将应用拆分成3个服务（如S1、S2、S3），每个团队负责维护自己的服务，相互之间不干扰。
当S1负责的团队在开发自己的服务时，不需要其他的团队进行配合，或者沟通协调成本低。它可以独立的去迭代、交付自己的微服务
此时会发现，多团队和微服务之间的架构关系能够映射起来，符合了康威法则，整体的研发、业务效率更高效。
问题
架构师大部分时间是在做技术性的问题，有很多架构师认为只要把技术性的问题解决好就行，今天学习了康威法则后，要我们去思考，架构师不仅仅是要做好技术架构，同时要了解组织的组织架构。
4. 企业应该在什么时候开始考虑引入微服务(微服务架构的适用性)
横坐标代表的业务系统的复杂性，纵坐标代表的生产力。
一般来说，我们的企业在刚开始起步的时候，业务复杂性不高，因为刚开始开发的业务系统是来验证企业的商务模式，用户量不是很大，很小，开发的系统功能也不是很复杂。
这个时候我们是采用微服务，还是单块应用服务呢？
一开始是不推荐使用微服务的，因为微服务对基础设施是有要求的，需要前期的投资。刚开始使用微服务的话，生产率力反而会降低。建议先从单块应用开始，开发成本低，不需要引入过多的研发就可以交付一些功能给到用户去使用。
随着应用的市场占有率增高，越来越成功，用户越来越多，系统的复杂性也会变高。此时系统如果还是单块的话，就会违背康威法则，就会出现团队的规模和单块应用之间的矛盾。生产力会随着业务系统的复杂性提高而降低。此时可以考虑引入微服务来解决这样的问题。在一些初创公司大都可以看见单块应用的影子，中大型互联网公司才可以看见微服务的身影。
坐标系上有一个交叉点，这个点个人认为是企业应该考虑引入微服务的点。即业务规模的复杂性已经达到了一个点，单块应用已不再适合，微服务会给研发效率、交付效率带来一个巨大的推动；如果此时企业开始考虑投入微服务，后续的研发整体对业务的支持大大的优于单块服务，
这个点如何去把控呢？需要架构师去权衡。个人建议，业务的研发+团队人数达到百人时可以考虑采用微服务架构。
刚才谈到了微服务的适用性，有些架构师经常有这样的困扰，我了解微服务架构，我也知道这个系统可以用微服务架构去设计，那我应该是一开始的时候就走微服务，还是设计成单块呢？
这里我们有一个原则，单块优先。
右边的图上方是研发直接走微服务架构，并不推荐，因为一开始的时候，对业务领域不是很理解，很难去把控怎么去拆分服务，划分服务的边界，另外可能花了很多时间去开发这个微服务，但这个应用市场占有率不高，不是很受到用户接受的。即商务模式没有被验证过，风险有点高。
右边的图下方是研发走单块优先的架构，即先去开发一个单块应用，这些功能是打包在一起的（123456）。随着业务的不断推进，团队规模的不断扩赞，作为架构师，对业务领域了解加深，此时单块应用已经不能满足业务的发展需求了，研发效率开始下降，到了一个点，就发现需要把有些功能拆出来（4），因为业务需要，团队规模也达到了一定的量级，后面陆陆续续可能发现团队规模更大了，这个时候可以把其他功能点陆陆续续的拆出来，最后变成一个微服务架构。
思考
业界很多架构师有着不同的架构理念，一种架构师认为我们的架构是设计出来的；另一种架构师认为我们的架构是演化出来的？你支持哪种呢？或者什么样的应用应该采用什么样的架构理念呢？
5. 什么样的组织更适合微服务
前文分享过康威法则，我们认为康威法则是微服务的组织原理，即设计系统的组织其产生的设计等价于组织的沟通结构。这一小节我们来细化一下，什么样的组织更适合微服务架构呢？
Netflix前架构师阿德里安·克罗夫特在他的一篇技术博文中分享了Netflix怎样来根据微服务的原理来进行组织架构调整的。博文大意如上图所示。
传统企业是怎样组织团队的呢？横坐标代表业务价值流的一个交付过程，一般来说，业务需求是从产品开始，到研发、DBA，最后上线运维（按横坐标来流动）。纵坐标表示业务能力，一般的公司可能有不同业务线，不同的业务部门、团队。在传统企业中，团队的划分是严格按照职能的。
当有项目到来时，会从每个团队抽调一些人来组成项目的交付团队。项目完成后，这些人一般都会回到各自的职能团队。
传统方式划分团队有什么样的劣势呢？
沟通协调成本大，因为价值流从一个团队到另一个团队传递的过程中，需要很多的沟通协调。
比方说产品获得需求后，需要和用户体验和研发团队进行多次的需求的确认。研发和测试同理，研发完成后，交付给测试团队去测试，其中两边涉及很多的沟通协调。测试通过后，交付到生产，测试团队和运维团队又要进行沟通，产品反馈周期长，一旦产品在线上出了问题，需要漫长的时间才能反馈给测试和研发，进而反馈到产品。
总体来说，研发效率低下，对业务的支持比较慢。
在微服务模式下，可能更需要一种新型的团队组织方式。称之为基于微服务的跨职能微服务产品团队。
比方说每个微服务，或是业务线，不再是传统严格的职能区分，而是每个团队内部既有产品专家，又有用户体验专家，研发、测试专家等。整个形成一个端到端的闭环。这些人围绕在微服务周围进行开发测试和交付。不是像原先的项目一样，项目结束了回到各自的所属团队，已经没有职能的划分了；而是围绕微服务组织团队。这群人基本就不走了，围绕在微服务周围不断地进行迭代。
后台的运维团队、DBA团队以产品的方式来交付。他们交付的是什么呢？交付的是一个平台产品（他们被称为平台团队），即把计算、网络、存储、持续交付的能力封装到一个平台内，对外提供一个API来支持不同的业务线进行快速的交付迭代。
在微服务模式下，有一种End-end Ownership，即端到端控制权，微服务整个团队是围绕微服务这个产品来组织的。这个团队内部的人同时要负责架构、设计、开发、评审、测试、发布、运行和支持，整个形成一个闭环（如右图所示）。
团队规模一般来说，根据亚马逊提出的两个披萨原则，即一个团队的规模大致十几个人左右，两个披萨就能搞定。亚马逊的CTO也曾说过 “Who Build It, Who Run It”
思考
Netflix前技术总监阿德里安·克罗夫特说过，”微服务架构本质上是一种组织架构的重组”。你怎么认为呢？
6. 如何理解阿里巴巴提出的微服务中台战略？
微服务的中台战略起源：马云2015年去欧洲的一家公司supersell参观，发现这个公司的创新能力非常强，团队的规模很小，但是开发效率很高。他们就是采用中台战略。马云感触很深，回国后就在集团内部推出了中台战略。
IasS云平台：一般由基础运维团队负责，提供底层的基础设施来支撑整个技术的研发。（Infrastructure-as-a-Service 基础设施即服务）
PaaS云平台：Platform-as-a-Service 平台即服务
核心业务层：互联网公司都有自己的核心领域服务，即自己的核心业务。
应用：传统的H5主站、App应用；第三方接入渠道，如开放平台，与自己公司有紧密关系的联盟商通过API方式进行调用我们提供的服务。
如何理解大中台、小前台战略呢？
大中台要强化技术中台和业务中台基础设施，小前台则是让这些应用、前端的业务更小更灵活，可以根据市场的变化，业务的需求不断地去迭代出新的应用出来。当我们下面的中台比较厚实，做的比较完善，它对上层应用的支撑能力也就越强。打个比喻，就是土壤越肥沃，越适合生长不同的生物，打造好的生态系统。
最终的目标是 赋能业务持续的创新，产生出不同的业务模式，快速的响应市场的需求。
在整个中台战略层次当中，有几个是跟微服务比较密切的。
PaaS层，它其中的内容可以理解为微服务的基础设施层。
核心业务层，每个公司不同领域的核心服务将其微服务化、抽象化，沉淀下来的一些核心能力。依赖于下层的PasS云平台、大数据、商业智能等；同时向上支撑各个不同业务线去交付他们的业务应用。
问题
每位架构师如何利用中台战略在自己的公司中进行实践呢？