演讲嘉宾简介：李小平（花名：愚奇），阿里云智能中间件首席架构师。
以下内容根据演讲视频及PPT整理而成。
本次分享主要围绕以下四个方面：
一、数字化转型和中台对企业技术架构所带来的挑战
二、微服务架构的应对之道
三、云原生微服务架构的应对之道
四、阿里云走过的路径
一、数字化转型和中台对企业技术架构所带来的挑战
数字化转型和中台对企业技术架构带来了挑战
如今，各大企业都在进行数字化转型。在中国，阿里巴巴首先提出“中台”的概念，而中台正是帮助企业进行数字化转型的良好实践。企业数字化转型会为企业技术架构带来两点改变，即一切业务数据化和一切数据业务化。这将会导致企业的软件生产流程发生巨大变化，促使传统企业向着互联网类型的软件企业进行转变。此外，由于生产线中存在更多的需求和软件设计等，这都会为企业的技术架构带来更多的挑战。
核心问题：软件复杂性
以上的挑战从更高的维度来看，可以归结为软件复杂性问题。《人月神话》一书的作者Fred Brooks有一番经典言论，即“软件复杂度问题很多时候都是由于软件规模的不断增加所造成的，而且软件复杂度的增加与软件规模的增加并不是线性关系”。
我们的讨论范围
本次分享的讨论范围仅关注于技术领域，而且因为市面上很多书籍都对于微服务架构都有详细介绍，因此本次分享将更多地关注企业高层技术架构的非功能性分析、组织沟通结构、流水线效能以及商业影响等方面，不会讨论具体的架构设计方案。
典型场景
如下图所示的是大部分企业中的组织架构和软件生产流水线概况。在组织结构中，按照功能结构方式划分职责，通常会有需求分析师、架构师、业务分析师、前端开发、后端开发、质量保证以及运维人员，这样的组织结构就构成了企业软件生产流水线中的各种角色。对于企业软件生产流水线而言，大部分企业的流水线包括需求分析、架构设计、总设/详设、代码开发、测试验证、发布上线、监控运维以及错误处理等，这就是本次分享主要讨论的典型场景。在这样的典型场景里面，我们最主要需要关注的是模型下的技术复杂度、实现成本以及组织结构和生产流水线对应的技术架构会为业务价值带来什么影响。
简单的情况（小于5人）
很多时候，团队规模小或者简单将会带来更高的快捷性，因此对于团队小于5个人的场景就不再做过多的讨论了。因为在这样的场景中，上述提到的多个角色将会合并，进而形成“快捷、方便”的企业流水线，而且也未必会遵循前面提到的流程和步骤，因为在这样的场景下，沟通非常迅速。很多时候不会涉及到软件的开发复杂度问题，而涉及到的只是技术复杂度问题。
中大规模下的环境相互影响问题
本次分享将会主要聚焦于中大规模的软件生产环境，在这样的环境中往往存在比较多的问题，本次分享中将会选取几个较为典型的问题进行分析。第一个问题就是由于多个开发或测试人员共用一个环境所带来的相互影响，这样的相互影响在很多企业中都在发生。因为这些人员共用了一个开发或者测试环境，而这些环境的使用者众多，其中的一个使用者在该环境中所做的一次发布或者变更，都会导致其他依赖了这一环境的人员或者业务模块出现问题，进而可能导致整体问题。每次出现问题，都需要软件生产线管理者对于环境进行修复，避免进一步影响更多的工作。当这种场景所造成的问题越来越大的时候，软件生产线的管理者不得不通过流程来约束和规范大家对于环境的使用行为。
中大规模下的发布干扰问题
第二个典型场景就是同一个软件需求往往会由多个部门同时进行开发。此外，软件生产线也不会一次只处理一个需求，而是多个需求同时迭代。团队在进行需求开发的时候，往往会中间插入一些高优先级的需求，而客户要求高优先级需求尽快上线，这就会使得原来位于生产线中的其他还没有完成的需求处于尴尬位置，如果跟随高优先级需求同时上线，就会导致整体或者部分功能不可用；而如果不上线，那么已经完成的这部分代码很难从现有的代码分支中剔除出去，这就是发布所带来的相互干扰问题。这些干扰问题从本质上就是由于不同的需求有不同的优先级和排期，而需求的实现代码又有不同的模块依赖关系，而这就使得整体的发布周期变长，协调成本变高。相应的协调工作不断增多，使得组织不得不考虑使用流程化的方法进行整体发布。很多企业则会采用按周期进行发布，这就使得开发人员更累，因为往往需要在进行多分支之间的处理。
中大规模下的数据干扰问题
此外，还经常会遇到数据干扰问题。这是因为不同的数据模块共同访问相同的数据库表或者KV存储导致的，这种共同的依赖导致一个模块需要改变数据库表或者KV存储的Schema的时候，另外一个使用相同数据库表或KV存储的模块不得不进行回归测试和发布，即使该模块并没有进行任何业务代码的修改。当数据上形成的依赖增多的时候，相应的协调、沟通工作也会大大增加，需要让所有的发布模块进行代码级、数据级的依赖分析，进而在每次发布时进行准确的依赖测试，并基于回归测试判断发布质量，而且需要做Schema的兼容性设计。
中大规模下的生产流水线分析
对于以上问题而言，当回到组织流水线来看，都是由康威定律中所描述的沟通问题导致的。在如下图所示的组织结构中，由于不同角色在生产流水线的不同阶段都有相应的工作，他们之间需要进行不断的沟通和协调。在这样复杂的沟通结构中，势必造成相应角色对于相应流水线的强依赖关系。如果这种强依赖关系不断扩散，那么相应的沟通复杂度就会不断放大。在这种传统生产流水线模式下面，技术复杂度显然会随着软件规模的扩大而不断扩大，当组织的规模增大之后，组织之间的内耗就会增多，沟通成本增加了。同样的，管理成本也会增加，不仅是对人的管理，也包括对于工具、环境的管理等。在这样的场景下面，需求响应速度会不断变慢，并且容易触发稳定性、关联性Bug，进而影响用户体验。当软件规模不断增大的时候，传统的软件生产流水线就无法满足企业要求了。
二、微服务架构的应对之道
微服务架构随着软件规模的扩大而被大家采纳
随着软件规模的不断扩大，新的技术架构不断涌现出来。从2000年的SOA架构，到2008年的互联网架构，以及2015年的微服务架构。与此同时，软件企业和软件从业者的规模则也是不断增加的。微服务架构本质上所解决的问题是随着软件规模不断扩大而出现的组织复杂度、生产流水线复杂度和技术复杂度问题。
现在的主流微服务架构
现在的主流微服务架构比较多，如果做一个抽象可以如下图所示。可以看出，所有请求很多时候会从API Gateway过来，并且以服务调用的方式送到不同的微服务里面，微服务之间通过远程服务调用的方式来发生关系，微服务自己通过服务发现的模式进行注册和销毁。同样，会有相应的服务管理模块对微服务进行治理。在这样比较典型的架构里面可以看到，其不仅在技术架构上面发生了变化，在流水线和组织结构中也要发生变化。在传统架构中，组织是按照部门职能进行划分的，而在微服务架构中，则要求按照业务域进行划分，比如客户域、订单域。在一个业务域下面，自身会形成闭包，不仅包括了架构的闭包，也包括了人员角色的闭包，闭包中包括了从需求分析，到相应的设计、开发、质量保证、运维以及运营等相应的人员，让他们一起负责整体业务。实际上，就是对于大颗粒度业务进行服务级别的拆分，
微服务下的生产流水线分析
微服务下组织结构的拆分会对于生产流水线造成巨大改变。如下图所示，原来所有的业务人员都在同一条生产流水线下面，现在则变成了每个业务域都有至少一条属于自己的生产流水线，对于企业而言，就形成了多流水线并行的情况，这样就显然提升了企业生产的并发度，减少了业务单元之间的相互依赖，从而提升了整体效率。在微服务生产流水线下面，企业强调微服务做合理拆分，这样的拆分往往是通过领域方式实现的，比如按照聚合根方式。拆分完成的服务具备高内聚、低耦合的特征。在这样的服务中，很显然服务模块内部技术复杂度降低了，这是因为对于模块之间的交互进行了技术架构和业务架构上的规范，从而使得一个服务所需要关注的数据下降了，因此其复杂度也会随之下降。但从技术的角度，原来是一个大的服务包，现在拆分成若干个不同的服务包，服务之间就会存在比较多的调用关系，这个时候再分布式场景下会使得复杂度增加。从实现的成本上来看，由于多流水线并行，因此企业的沟通成本将会下降，因为只有一个大的业务需求需要横跨多个业务单元的时候才需要进行沟通，而且都是在业务层面进行沟通，而不会在软件的实现、软件环境的共用上发生关系，因此就减少了组织之间的沟通复杂度。当然这里的前提是企业自动化能力需要跟上，如果没有强大的自动化能力，那么做微服务将会成为企业的巨大噩梦。这是因为原来架构下，运维人员只需要维护一组服务，现在则需要维护多组服务；对于测试人员也是一样的。因此，在微服务架构下，需要相应的测试、运维以及开发提升整个生产流水线的自动化能力，从而提升整体研发和运维效率。这也正是DevOps理念所强调的提升持续集成和持续交付的能力。从业务价值来看，微服务流水线使得需求响应的速度得到了极大提升，同时按照业务领域而非人员职能划分组织结构的方式非常符合中台理念，也非常符合中台、前台相互分离的原则，进而快速迭代的业务需求。
微服务架构下的环境问题解决
回到前面所提到的传统架构所面临的问题，考虑一下微服务架构如何解决。对于环境问题而言，在微服务架构下面，由于提倡DevOps，不断增强CI/CD能力，使得共用环境变成了每个小组拥有单独的环境。而因为持续集成的能力提升，小组内可以有生产测试环境和试飞环境，也就是说当开发人员完成代码实现之后可以先提交到试飞环境，在试飞环境中完成CI以及CD相关的工作。如果所有的工作验证完成之后，再自动化地将发布的模块同步到小组内的预发环境中去做SIT。这就使得每个业务领域的小组都能够实现快速迭代，而不是通过流程规范来约束大家的行为。
微服务架构下的发布干扰问题解决
对于发布干扰问题而言，在微服务架构下，按照服务的颗粒度进行发布，这样就比较容易实现按需求进行发布。如果某个符合需求横跨多个领域，也能够得到快速排期。这是因为可以在顶层实现业务分解，从而进入到每个不同的业务领域时就变成了单独的需求，只需要在顶层去协调需求的任务排期情况即可，相互之间的干扰得到极大降低。这使得每个服务都可以随时发布，并且快速发布、按需发布，并降低了每个服务发布质量对于整体系统质量的影响。
微服务架构下的数据干扰问题解决
对于数据干扰问题而言，微服务要求不同的服务使用不同的数据源，因此从本质上就打断了服务之间的数据依赖问题。当这种设计模式应用到微服务的设计中之后，当业务模块中需要访问数据通常有两种形式。第一种方式是通过API或者消息方式；第二种是通过Change Data Capture（CDC）方式实现，因为如果对于数据模块存在依赖，往往是依赖其局部视图，因此跟踪另外一个模块数据发生变化的消息，当接收到所订阅的数据变化消息之后，服务可以在自己的数据视图中进行改变，这样就彻底消除了服务之间的数据依赖。
微服务架构的“双刃剑”问题
正如Fred Brooks所说的“没有银弹”。其实任何的技术往往都是“双刃剑”。那么，在微服务架构下面，什么是“双刃剑”问题呢？
微服务架构面临的主要挑战
微服务很好地解决了大规模软件的复杂度问题，但是也带来了其他问题。这些问题包括以下几点：
分布式规模的增加带来的技术复杂度问题：特别是像今天云计算在不断地普及，企业在云计算环境下如何解决分布式问题变成一个巨大的挑战。
节点实例增加带来的稳定性降低：以往架构使用一台计算能力强的机器做发布，而今天在微服务架构下面，系统不断拆分使得出现更多的服务实例，因此需要增加更多的节点，导致稳定性降低。
快速扩缩容响应互联网规模的大促：互联网的不断普及使得其与更多的业务发生关系，这意味着对业务架构突然产生大的扩缩容要求。
分布式环境的调试、故障诊断和监控关联性分析：微服务使得运维人员进行这些工作时会出现困难，需要去不同的机器上采集信息并进行关联性分析。
提升开发运维的自动化能力：微服务部署的复杂度增加导致对此产生更高的需求。
多语言开发、容灾、安全：微服务允许使用多语言实现业务，并且在容灾和安全方面都面临较大挑战。
三、云原生微服务架构的应对之道
云原生技术随着云计算的推广而被广泛使用
只要有需求就会不断涌现出新的技术方案来解决问题。随着云计算技术的不断普及，云原生相关技术也逐渐被广泛使用，从2001年的虚拟化，到2013年容器技术的出现，对于云原生技术都带来了非常大的变革。在2015年，业界正式提出云原生技术来去解决软件生产流程中的各种问题。
云原生中间件
云原生技术的普及就带来构建所需要的中间件发生的巨大变化，导致云原生中间件这个新领域的出现。与以往的中间件不同，云原生中间件除了能够接受二进制包并进行相应的部署以外，还可以直接解决高可用问题，不需要关注弹性等问题，而只需要关注业务实现本身以及排错等。除此以外，巨大的变化在于Service Mesh技术上面，原本像安全、限流、降级、熔断等分布式场景下的设计模式是被沉淀到了Spring Cloud、Dubbo这样的框架中，而在云原生中间件中，这些模式则被沉淀到了Service Mesh中，实现了与应用的彻底剥离。分布式模式与应用的彻底剥离带来了几个优势：开发人员不需要再去关注分布式架构下面的设计复杂度问题；不同的开发框架、不同语言所开发的微服务都可以同样地共享这些能力，为业务开发带来了极大便利；原本这些分布式设计模式都存在与开源框架中，没有商业服务，而在云基础服务中，这些设计模式都能够被类似于Service Mesh的基础设施提供，也就是所谓的云厂商提供，因此能够大大提升服务质量。除了Service Mesh，在云领域大家非常关注的SLA、如何做稳定性的安全生产、如何做持续的IT治理等能力都能够由云原生中间件层提供。而云原生中间件会架构在很多BaaS服务上面，同时也会架构在容器上面，这样的设计使得对于应用架构带来巨大改变，那就是将一个应用所依赖的第三方组件交给专业的产品提供，不仅提供SDK，还会提供专业服务，扩缩容以及运维都由云厂商提供。
如何解决稳定性问题
在云原生环境下面如何解决稳定性问题呢？由于在云原生中间件里面所提倡的是事件驱动架构，这种架构从设计本身来看是具有巨大优势的，可以进一步减少服务之间的耦合。原本服务之间可能是通过RPC调用方式形成的耦合，但在事件驱动的架构下，服务之间通过事件进行传递，而事件本身具有松耦合的特征，因此事件驱动架构将为整体架构带来更强的韧性。同样的，由于Service Mesh接管了稳定性相关的所有云设计模式，比如熔断、限流、降级等，就会使得应用变得更加稳定。新的技术架构，比如Serverless、BaaS等使得应用无需关注分布式环境中的运行位置，减少了对于第三方组件的依赖，进而提升了整体的稳定性。
如何解决弹性问题
无服务器架构模式按照业务峰值进行动态伸缩，避免了手工扩缩容。Service Mesh可以根据流量观测以及资源消耗情况实现动态扩缩容。由于BaaS组件的出现，使得应用非常易于实现计算存储分离，进而简化自动扩缩容的处理。
如何解决可观测性问题
在云原生架构中存在Open Tracing标准方便不同的软件架构实现Tracing，从而通过tag机制拉通业务流量与软硬件基础设施的可观测性，这是原来架构所不具备的。此外，在Service Mesh和Serverless层实现了请求级的SLA测量，能够很清晰地看到用户查询的某个接口是否达到了100 QPS的SLA。同样的，对于用户的查询还可能涉及主数据等查询，这样可以对依赖关系进行分析来形成SLA链条并进一步提升。进一步看，今天云原生的基础设施由于具备了业务流量，因此能够方便将网络流量、服务流量以及业务流量和基础设施运行情况形成大数据，进而比较好地帮助企业进行持续的IT服务治理。
生产流水线分析
基于DevOps的生产流水线、基于按领域划分的组织结构，其技术复杂度得到了很大降低，特别是分布式环境下的技术复杂度得到了极大降低，这是因为分布式环境下的设计模式下沉到了云原生中间件这样的云基础设施当中，将分布式环境中的很多非功能性需求从业务框架或者业务包中剥离出来，直接放到了云厂商所提供的软件基础设施当中。在实现成本上面，由于新增加了Serverless、Service Mesh架构，使得如今基于云原生微服务的这些软件对于所依赖的硬件可以实现按用量购买，从而进一步降低整体CAPEX。同样的，这些技术的更新对于业务带来更多的价值，可以进一步提升用户体验。这是因为在云原生基础设施和云原生微服务架构里面，软硬件的稳定性都得到了极大的提升。此外，在这样的基础设施里面，开发可以使用不同的技术栈、开发语言来快速实现业务，能够帮助业务快速上线，并通过观察业务试运行的情况判断是否进一步推广，因此多技术栈能够帮助企业进一步加快业务迭代速度。
架构风险控制
正如前面所说的“没有银弹”，在云原生微服务的架构之下，也无法解决所有问题，因此需要在架构层面进行风险控制。推荐大家在组织结构中增加架构控制委员会，这一角色最主要是从组织架构、技术架构以及业务架构的不断更新和迭代的过程中不断保持匹配。除了控制变更，架构控制委员会还需要负责架构度量分析、架构风险治理以及规范架构设计原则等。对于一个组织而言，架构控制委员会可以是架构组，也可以将这以角色外包给其他咨询厂商，从而保证企业架构技术演进和企业生产流水线比较好地匹配，进而使得技术演进与业务需求具有更好的匹配。
架构迁移路径
微服务架构具有很多优点，今天无论是现有应用还是新构建的应用都会向着云原生微服务的架构上进行演进。
对于现有的应用，特别是历史债务比较沉重的应用而言，建议首先在架构分析层面充分地梳理技术和业务架构的风险点，特别是遗留系统部分；其次考虑如何进行集成，对于集成方面进行充分设计；最后，即使面对沉重的历史负担，也需要进行必要的改造，这是因为架构的迁移并非是一天能完成的，但不能迟迟不动，而可以通过必要的改造逐步迭代完成。
而对于新构建的应用，由于其没有太多的历史负担，一般而言迁移到微服务比较容易，因此也会提供最佳实践为企业提供参考。通过对于最佳实践的分析，可以了解做架构迁移的风险，分析完成之后可以依据最佳实践进行小范围POC验证，之后通过阿里云等云计算厂商所提供的解决方案和迁移工具实现快速、低成本上云。
四、阿里云走过的路径
阿里走过的路径
前面分享了很多的技术，而阿里巴巴作为一家巨大的互联网公司，走过了一条完整的技术路线，从2008年的互联网架构，到微服务架构再到云原生架构。今天，除了应用上云，不断迭代IT基础设施、应用基础设施之外，阿里巴巴还将相应服务输出到外面，将最佳实践也不断分享给外界，因此也希望更多的公司能够尽情拥抱云原生微服务架构。
