架构演化：云原生时代开启之系列一演化篇

信息技术从出现伊始到渐成主流，其趋势经历了软件、开源和云三个阶段：

软件改变世界。纵观人类社会漫长的发展历程，农耕时代、工业时代与信息时代可谓是三个明显分水岭，每个时代人类涉及的领域范畴均喷井式增长。作为信息时代最重要的载体，互联网越来越成为当今社会关注的焦点，互联网的基石之一，软件正在迅速地改变着这个世界。

开源改变软件。随着软件行业的积累与成熟，相比于重复制造轮子，站在巨人的肩膀上则更加容易和快速地创造出优秀的新产品。随着开源文化的认可度越来越高，使用优秀的开源产品作为基础构架，快速搭建系统以实现市场战略是当今的最优资源配比方案。

云吞噬开源。对互联网近乎100%可用性的需要，仅通过开源产品搭建并运维一个高可用、高度弹性化的平台并非易事。因此，提供技术思路的同时，进一步提供整套云解决方案，以保障不断扩展的非功能需求，是当今新一代互联网平台的追求。

在信息技术的大潮中，每一次通信的升级，都会对世界的合作模式产生改变。随着互联网在本世纪初大规模的接入，互联网由基于流量点击盈利的单方面信息发布门户的web 1.0业务模式，转变为了由用户主导而生成内容的互联网产品，即web
2.0业务模式。因此，互联网应用系统所需处理的访问量和数据量均急速增长，后端技术架构也因此面临着巨大的挑战。这一阶段的互联网后端架构大多由All in One的单体式应用架构渐渐的转向为更加灵活的分布式应用架构；而企业级架构由于功能复杂，而且并未出现明显的系统瓶颈，因而并未跟进。后端开发由单一技术栈渐渐区分开来，越来越明显的划分为企业级开发和互联网开发。企业级开发和互联网开发的差别不仅在于技术栈，也在于工作模式，对质量的追求与对效率的提升成为了两个阵营的分水岭。

  随着智能手机出现以及4G信号的普及，互联网应用由PC端迅速转向更加自由的移动端，由于携带方便且便于定位，在出行、网购、付款等方面彻底了改变的现代人的生活方式。在技术方面，为了应对更加巨大的规模，单纯的分布式系统已经难以驾驭。技术圈也因此契机开启了一个概念爆发的时代，SOA、DevOps、容器、CI\CD、微服务、Service
Mesh等概念层出不穷，而Docker、Kubernetes、Mesos、Spring
Cloud、gRPC等一系列产品的出现，标志着云时代真正的到来。

云时代下的互联网架构变迁

互联网应用的业务特征决定它和企业级应用的诸多不同，主要有以下几点：

1.海量用户

互联网应用几乎无差别的服务于全世界所有的用户，与服务于局域网用户的企业级应用相比，它们的用户量基数差距很大，由海量用户产生的数据量也会成几何级增长。

2.产品迭代迅速

随着业务模式的快速拓展，互联网应用功能推陈出新的速度越来越快。在当今如此快节奏的时代，时间成本非常关键。

3.7*24不间断服务

互联网应用作为一个面向全球的服务，时区的差异，使得应用必须保证全天随时可用，每次宕机都会产生很大的损失。

4.流量突增

不同类型的互联网公司有着各自不同的流量突增场景。比如，电商类公司会在双十一这样的大促期间流量突增几倍、几十倍甚至上百倍；社交类公司会在热点事件爆发的时候流量突增。

5.业务组合复杂

很多互联网公司都是跨界巨头，即使并非跨界，在单一领域，编织一个大规模的成型业务也并不简单。以电商行业举例，在应用系统层面大致会划分为卖场、交易、订单、仓储、物流等主流程系统；搜索、推荐、社区、会员、客服、退换货等面向用户的前端系统；商品、价格、库存、配货、促销、供应链等面向后台员工的后端系统；以及广告、商家、支付、清算、财务、报表等面向合作伙伴的辅助系统。而每个应用系统又会划分为很多子系统。一个粗略的电商系统业务架构图：



由于互联网行业业务特征的特殊性以及势不可挡的扩张速度，相应的底层支撑的技术挑战也越来越大，究其根本原因是其不断扩张的规模。由规模而衍生的问题包括海量数据、响应迟缓、稳定性差、伸缩性差、系统繁多和开发困难等问题。

因此针对这些问题，互联网的技术架构也在逐渐的转变，以

集中式 –>分布式-> 云平台的方向演进。

从集中式到分布式架构

    集中式架构又叫单体式架构，在web2.0模式并未大规模兴起时，十分流行。进入新世纪以来，基于web应用的B/S架构逐渐的取代了基于桌面应用的C/S架构。B/S架构的后端系统，大都采用集中式架构，它当时以优雅的分层设计，统一了服务器后端的开发领域。


1.传统的三层架构模型

    在web
2.0刚开始流行的时候，互联网应用与企业级应用并没有本质的区别，集中式应用分为标准的3层架构模型：数据访问层、服务层和逻辑控制层。每个层之间既可以共享领域模型对象，也可以做更加细致的拆分。

由于NoSQL在当时还并未兴起，因此数据库访问层主要是关系型数据库的访问，出现了很多ORM框架。MyBatis及其前身IBatis、JPA以及它的默认实现Hibernate都是ORM领域中开源框架的翘楚。

服务层用于编写应用的具体业务逻辑，它需要一个使用便捷且可以对数据访问层和逻辑控制层能够承前启后的框架。Java官方所推荐的EJB
2.X过于笨重，大量的XML配置以及繁琐的部署方式，使得它使用起来非常不便。虽然后来Sun公司又推出的EJB
3.X，在使用上简化了很多，但依然无法成为Java开发的事实标准。由Rod Johnson这位业界大神开发的Spring
Framework，极大的简化了JavaEE的开发，它提供的IOC和AOP为开发者提供了便利，并且迅速地成为Java后端开发的实际标准。

    逻辑控制层，又叫MVC层，它是用于分离前台展现和后端服务的部分。由于Java的标准实现Servlet侵入了大量如HttpRequest、HttpResponse、HttpSession等Servlet
API。导致基于Sevlet开发的程序并不利于单元测试，而且其配置、跳转、表单封装等操作也需要做大量的重复工作，因此，产生了很多MVC框架用于改善开发工作。常见的MVC框架有Strtus
1.X，基于WebWork封装的Struts 2.X和Spring
MVC。初期Struts系列由于使用简单而备受青睐，后来随着Spring对MVC投入的加大，其更加清晰的设计理念以及强大的与Spring
framework的融合能力，使得它渐渐成为业界主流。

在这种All in One的集中式架构下，每个开发者都是全栈工程师。

由Spring + Struts（Spring
MVC）+ Hibernate组成的SSH框架套件或

由Spring + Struts（Spring
MVC）+ IBatis（MyBatis）组成的SSI框架套件成为技术选型的主流。


2.分布式架构、SOA和服务化

    然而，对于互联网应用规模的迅速增长，集中式架构并无法做到无限制的提升系统的吞吐量。它只能通过增加服务器的配置有限度的提升系统的处理能力，这种扩展方式被称之为垂直扩展。与之相对的扩展方式叫做水平扩展，它能够仅通过服务器数量的增减即可相应的提升和降低系统的吞吐量。这种分布式系统架构，在理论上为吞吐量的上升提供了无限扩展的可能。因此，用于搭建互联网应用的服务器也渐渐地放弃了昂贵的小型机，转而采用大量的廉价PC服务器。

    分布式系统的引入，虽然解决了整个应用的吞吐量上限问题，但它也并非银弹。分布式在带来便利的同时，也带来了额外的复杂度。分布式场景下比较著名的难题就是CAP定理。CAP定理认为，在分布式系统中，系统的一致性、可用性和分区容忍性，三者不可能同时兼顾。在分布式系统中，由于网络通信的不稳定，分区容忍性是必须要存在的，因此在设计应用的时候，就需要在一致性和可用性之间权衡选择。在一致性和可用性之间，互联网应用比企业级应用更加偏向可用性。因此，采用最终一致性代替传统事务的ACID强一致性。

随着分布式系统架构的普及，越来越多的互联网公司在重新审视一个并不是崭新，但却一直难于落地的概念，那就是SOA。

    SOA即面向服务架构，它是一个特别大的话题，可以简单的认为SOA约等于模块化开发 + 分布式计算。SOA需要从宏观和微观两个不同的角度讨论。宏观SOA面向高层次的部门级别、公司级别甚至行业级别，涉及商业、管理、技术等方面的综合和全局的考虑。SOA最主要是面向宏观层面的架构，其带来收益也最能在宏观的高层次上体现出来，因此，很多业界专家都认为SOA概念过于抽象、不接地气。微观SOA则面向团队和个人，涉及具体的服务在业务、架构和开发上的考虑，架构体系上包括服务治理、服务编排等等。在微观层面的SOA则更容易讨论和实施。

    由于分布式系统是如此复杂，因此也产生了大量的分布式中间件和分布式数据库，用于简化分布式系统的开发。服务化的架构设计理念也被越来越多的公司所认同。2011年前后，阿里开源的Dubbo，是对后世影响深远的一款分布式服务框架，也彻底的掀起了为早已拉开帷幕的分布式和SOA时代的最强音。服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能也一个个趋于成熟。


3.[b]自动化运维[/b]

[b]    随着分布式系统的愈加成熟，越来越大的规模的应用和越来越复杂的系统构成也随之而来，服务器的数量迅速地从几十上百台发展成为了成千上万台。企业内部服务器数量的大幅增长，使得出现故障的服务器频次也大幅增加，手工运维时代的瓶颈也随之到来。运维工程师越来越难以远程登录到每一台服务器，去搭建环境、部署应用、清理磁盘、查看服务器状态以及排查系统错误。[/b]

急需与开发技术体系配套的，是自动化运维体系。自动化运维工具主要包括两大类：监控自动化工具以及流程自动化工具。

    监控自动化工具可以对服务器的CPU、内存、磁盘IO、网络IO等重要指标进行主动式的探测监控，一旦指标超过或接近阀值则自动通过邮件、短信等方式通知相关责任人。Nagios、Zabbix等系统监控工具可以有效的解决这一问题。

流程自动化工具主要针对服务器的维护和应用上线部署等日常操作的自动化和标准化。Puppet、Chef、Ansible和SaltStack等自动化运维管理工具的出现，快速的将运维工作推向自动化，让一个运维工程师可以很容易的维护上千台服务器。

4.解放交付的DevOps

    分布式架构解决了互联网应用吞吐量的瓶颈；越来越成熟的分布式中间件也屏蔽了分布式系统的复杂度，提升了开发工程师的工作效率；自动化运维工具也提升了运维工程师的工作效率。但是，由于目标不同，在固有的开发和运维划分为不同部门的组织结构中，部门之间的配合并不总是很顺畅。开发部门的驱动力通常是频繁地交付新特性，而运维部门则更关注服务的可靠性。两者目标的不匹配，就在开发与运维部门之间造成了鸿沟，从而降低了业务交付的价值的速度。

    直到DevOps方法论的出现，开发与运维之间的鸿沟才得以渐渐跨越。它是一系列可以帮助开发工程师和运维工程师在实现各自目标的前提下，向最终用户交付最大化价值和最高质量成果的基本原则和实践。DevOps在软件开发和交付流程中强调在产品管理、软件开发以及运维之间的沟通与协作。

DevOps是一种公司文化的变迁，它代表了开发、运维和测试等环节之间的协作，因此DevOps可以由多种工具组成一个完整的DevOps工具链，见下图：

从分布式到云原生架构

    随着虚拟化技术的成熟和分布式架构的普及，用来部署、管理和运行应用的云平台被越来越多的提及。IaaS、PaaS和SaaS是云计算的3种基本服务类型，它们是关注硬件基础设施的基础设施即服务、关注软件和中间件平台的平台即服务以及关注业务应用的软件即服务。容器的出现，使原有的基于OpenStack的云主机应用，彻底转变为更加灵活和轻量的容器+编排调度的云平台应用。

1.新纪元的分水岭 - 容器技术

    过去几年云平台在不断地发展，但应用程序在云平台运行，仍然需要为不同的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。

    Docker的出现成为了软件开发行业新的分水岭；容器技术的成熟，也标志技术新纪元的开启。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。就像当年智能手机的出现改变了整个手机行业的游戏规则一样，Docker也大有席卷整个软件行业，并且进而改变行业游戏规则的趋势。通过集装箱式的封装，开发和运维都以标准化的方式发布的应用，异构语言不再是桎梏团队的枷锁。

2.新纪元的编排&调度系统

    而Kubernetes、Mesos和Docker
swarm则为云原生应用提供的强有力的编排和调度能力，它们是云平台上的分布式操作系统。

   
Kubernetes是目前世界上关注度最高的开源项目，它是一个出色的容器编排系统。Kubernetes出身于互联网行业的巨头Google公司，它借鉴了由上百位工程师花费十多年时间打造Borg系统的理念，通过极其简易的安装，以及灵活的网络层对接方式，提供一站式的服务。

    Mesos则更善于构建一个可靠的平台，用以运行多任务关键工作负载，包括Docker容器、遗留应用程序(例如Java)和分布式数据服务(例如Spark、Kafka、Cassandra、Elastic)。Mesos采用两级调度的架构，开发人员可以很方便的结合公司业务场景自定制MesosFramework。

    通过Docker、Kunernetes以及Mesos的出色表现，为运维工程师的工作模式带来了颠覆性的改变。他们再也无需像照顾宠物那样精心的照顾每一台服务器，而是只需要像照顾牲畜那样，将出问题的服务器汰换掉即可。业务开发工程师不必再过分关注非功能需求，只需专注自己的业务领域即可。而中间件开发工程师，则需要开发出健壮的云原生中间件，用来连接业务应用与云平台。

3.微服务

    单体应用虽然简单且深入人心，但是随着越来越多的应用被部署在云端，它的劣势就体现的愈加明显。因为应用变更的范围和周期被捆绑在一起，即使只变更应用的一部分，也需要重新构建并部署整个单体应用，而且无法对需要更多资源的部分模块单独扩展，而是必须将整个应用整体扩展。这样粗粒度的划分，不利于系统的管理和资源的利用。因此，人们越来越倾向于将应用合理的拆分。

    在过去几年中，微服务已经迅速的成为了技术圈最热门的术语之一，微服务是一种架构风格，它将一个复杂的单体应用分解成为多个独立部署的微型服务，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制，如：RESTFul
API。服务可以使用不同的开发语言和数据存储技术。通过微服务的拆分，系统可以更加自由的所需资源分配到所需的应用中，而不是直接扩展整个应用。

    采用微服务架构风格的团队将围绕业务组织团队而非围绕技术组织团队，这一点和DevOps有异曲同工之妙。单体式架构将大型应用拆分时，通常需要根据技术层面划分为UI团队、后端开发团队好数据库团队。这种团队的划分方式，使得简单的更改也会导致跨团队协作。

    在容器技术、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。

    随着云化技术的不断进展，云原生的概念有应运而生。在现有业务代码不改变的情况下，分布式系统无缝入云，那么需要改变的就是中间件。因此分布式中间件向云原生中间件的变迁，即是本书的重点。

以上内容节选自《云原生分布式架构》一书

【内容简介：互联网架构不断演化，经历了从集中式架构到分布式架构，再到云原生架构的过程。云原生因能解决传统应用升级缓慢、架构臃肿、不能快速迭代等问题而成为未来云端应用的目标。本书首先介绍了架构演化及云原生的概念，让读者对基础概念有一个准确的了解。接着阐述容器调度、服务化、分布式等体系的原理，讲解分布式中间件设计方法。最后辅以实战，以中心化和平台化角度切入，深度揭秘两大开源项目Elastic-Job和Sharding-JDBC的实现】

原文：https://mp.weixin.qq.com/s/jlZ5kVZdKkKdnU3UyFys4w

.NET社区新闻，深度好文，欢迎访问公众号文章汇总 http://www.csharpkit.com