微服务：微服务及其演进史
1 传统单体系统介绍
在很多项目的业务初期阶段，高速迭代上线是首要考虑的事情，对后期的容量预估、可扩展性和系统健壮性、高可用一般没有那么重视。但随着业务的发展，用户量、请求量的暴增，
发现原来的单体系统已经远远不满足需求了，特别是随着互联网整体的高速发展，对系统的要求越来越高。
但是物理服务器的CPU、内存、存储器、连接数等资源有限，单体系统能够承受的的QPS也是有限的，某个时段大量连接同时执行操作，会导致web服务和数据库服务在处理上遇到性能瓶颈。
为了解决这个问题，伟大的前辈们发扬了分而治之的思想，对大数据库、大表进行分割，可以参考我的《分库分表》，以便实施更好的控制和管理。
同时创建多个服务实例，使用多台服务机进行CPU、内存、存储的分摊，提供更好的性能。
1.1 单体系统的问题
1、复杂性高：由于是一个单体的系统，所以整个系统的模块是耦合在一起的，模块的边界比较模糊、依赖关系错综复杂。功能的调整，容易带来不可知的影响和潜在的bug风险。
2、服务性能问题：单体系统遇到性能瓶颈问题，只能横向扩展，增加服务实例，进行负载均衡分担压力。无法纵向扩展，做模块拆分。
3、扩缩容能力受限：单体应用只能作为一个整体进行扩展，影响范围大，无法根据业务模块的需要进行单个模块的伸缩。
4、无法做故障隔离：当所有的业务功能模块都聚集在一个程序集当中，如果其中的某一个小的功能模块出现问题（如某个请求堵塞），那么都有可能会造成整个系统的崩溃。
5、发布的影响范围较大：每次发布都是整个系统进行发布，发布会导致整个系统的重启，对于大型的综合系统挑战比较大，如果将各个模块拆分，哪个部分做了修改，只发布哪个部分所在的模块即可。
1.2 单体系统的优点
1、系统的简易性：系统语言风格、业务结构，接口格式均具有一致性，服务都是耦合在一起的，不存在各个业务通信问题。
2、易于测试：单体应用一旦部署，所有的服务或特性就都可以使用了，简化了测试过程，无需额外测试服务间的依赖，测试均可在部署完成后开始。
3、易于部署与升级：相对于微服务架构中的每个服务独立部署，单体系统只需将单个目录下的服务程序统一部署和升级。
4、较低的维护成本：只需维护单个系统即可。运维主要包括配置、部署、监控与告警和日志收集四大方面。相对于单体系统，微服务架构中的每个服务都需要独立地配置、部署、监控和日志收集，成本呈指数级增长。
1.3 单体服务到微服务的发展过程
EUREKA的注册中心逐渐被ZooKeeper和Nacos等替代了。
2 关于微服务
2.1 单一职责
2.2 轻量级通信
通过REST API模式或者RPC框架，实现服务间互相协作的轻量级通信机制。
2.3 独立性
在微服务架构中，每个服务都是独立的业务单元，与其他服务高度解耦，只需要改变当前服务本身，就可以完成独立的开发、测试、部署、运维。
2.4 进程隔离
2.5 混合技术栈和混合部署方式
团队可以为不同的服务组件使用不同的技术栈和不同的部署方式（公有云、私有云、混合云）。
2.6 简化治理
组件可以彼此独立地进行扩缩容和治理，从而减少了因必须缩放整个应用程序而产生的浪费和成本，因为单个功能可能面临过多的负载。
2.7 安全可靠，可维护。
从架构上对运维提供友好的支撑，在安全、可维护的基础上规范化发布流程，支持数据存储容灾、业务模块隔离、访问权限控制、编码安全检测等。
3 微服务演进史
我们前面已经了解了微服务的概念，通过百度指数可以看出，从2012年之后，微服务的发展有显著的发展趋势。
目前业内的微服务相关开发平台和框架还是比较多的，比如较早的Spring Cloud（使用Eureke做服务注册与发现，Ribbon做服务间负载均衡，Hystrix做服务容错保护），
阿里的Dubbo，微软的.Net体系微服务框架 Service Fabric，再到后来进阶的服务网格(Service Mesh,如 Istio、Linkerd）。
那从12年开始到现在，微服务到底发展到哪个阶段了，在各个阶段的进阶过程中，又有哪些的变化。所以我们需要了解微服务技术的历史发展脉络。
下面的内容参考了 Phil Calçado的文章《Pattern: Service Mesh》，从开发者的视角，详细分析了从微服务到Service Mesh技术的演进过程，这边做了进一步的整理和总结。
3.1 第一阶：简单服务通信模块
这是最初的模样，开发人员最开始的时候想象的两个服务间简单的通信模式，抽象表示如下，两个服务之间直接进行通信：
3.2 第二阶：原始通信时代
上面的方式非常简单，但实际情况远比想象的复杂很多，通信需要底层字节码传输和电子信号的物理层来完成，在TCP协议出现之前，
服务需要自己处理网络通信所面临的丢包、错误、乱序、重试等一系列流控问题，因此服务实现中，除了业务逻辑外，还包含对网络传输问题的处理逻辑。
3.3 第三阶：TCP时代
TCP协议的出现，避免了每个服务自己实现一套相似的网络传输处理逻辑，解决网络传输中通用的流量控制问题。
这时候我们把处理网络传输的能力下沉，从服务的实现中抽离出来，成为操作系统网络层的一部分。
3.4 第四阶：第一代微服务（Spring Cloud/RPC）
TCP出现之后，服务间的网络通信已经不是一个难题了，所以 GFS/BigTable/MapReduce 为代表的分布式系统得到了蓬勃的发展。
这时，分布式系统特有的通信语义又出现了，如服务注册与发现、负载均衡、熔断降级策略、认证和授权、端到端trace、日志与监控等，因此根据业务需求,完成一些通信语义的实现。
3.5 第五阶：第二代微服务
为了避免每个服务都需要自己实现一套分布式系统通信的语义功能，随着技术的发展，一些面向微服务架构的通用开发框架出现了，如Twitter的Finagle、Facebook的Proxygen以及Spring Cloud等，
这些框架实现了分布式系统通信需要的各种通用语义功能：如负载均衡和服务发现等，因此一定程度上屏蔽了这些通信细节，使得开发人员使用较少的框架代码就能开发出健壮的分布式系统。
3.6 第六阶：第一代Service Mesh
上面的第二代微服务框架目前看着挺完美了，但整套微服务框架其实是很复杂的，比如Spring Cloud，聚合了很多组件。所以在实践过程中，会发现有如下诸多问题：
-
侵入性强。想要集成SDK的能力，除了需要添加相关依赖，业务层中入侵的代码、注解、配置，与治理层界限不清晰。
-
升级成本高。每次升级都需要业务应用修改SDK版本，重新进行功能回归测试，并对每一台服务进行部署上线，与快速迭代开发相悖。
-
版本碎片化严重。由于升级成本高，而中间件版本更新快，导致线上不同服务引用的SDK版本不统一、能力参差不齐，造成很难统一治理。
-
中间件演变困难。由于版本碎片化严重，导致中间件向前演进的过程中就需要在代码中兼容各种各样的老版本逻辑，带着"枷锁”前行，无法实现快速迭代。
-
内容多、门槛高。依赖组件多，学习成本高，即使通用分布式系统屏蔽了很多的实现细节，我们引入微服务框架并熟练使用也是要花费巨大的精力的。
-
治理功能不全。不同于RPC框架，SpringCloud作为治理全家桶的典型，也不是万能的，诸如协议转换支持、多重授权机制、动态请求路由、故障注入、灰度发布等高级功能并没有覆盖到。
- 无法实现真正意义上的语言无关性。提供的框架一般只支持一种或几种语言，要将框架不支持的语言研发的服务也纳入微服务架构中，是比较有难度的。
所以，第一代微服务架构 Service Mesh就产生了，它作为一个基础设施层，能够与业务解耦，主要解决复杂网络拓扑下微服务与微服务之间的通信，其实现形态一般为轻量级网络代理，并与应用以边车代理（SideCar）模式部署，同时对业务应用透明。
SideCar将分布式服务的通信抽象为单独一层，需要和服务部署在一起，接管服务的流量，通过代理之间的通信间接完成服务之间的通信请求。
所以在这一层中它能够实现负载均衡、服务发现、认证授权、监控追踪、流量控制等分布式系统所需要的功能。
如果我们从一个全局视角来看，绿色的为应用服务，蓝色的为SideCar，就会得到如下部署图：
如果我们省略去服务，只看Service Mesh的代理边车的网格应该是这样的：
流量经过的时候，会先被代理边车所劫持，然后再进入服务，所以它就是一个由若干服务代理所组成的错综复杂的网格。
3.7 第七阶：第二代Service Mesh
第一代Service Mesh由一系列独立运行的单机代理服务构成，为了提供统一的上层运维入口，演化出了集中式的控制面板，我们称之为控制面（control plane）。
控制面和所有的数据面（data plane，即代理边车）进行交互，比如策略下发、数据采集等。这就是以Istio为代表的第二代Service Mesh。
只包含控制面和数据面的 Service Mesh 服务网格全局结构图 如下：
从上面的结构图可以看出，Service Mesh 的基础设施层主要分为两部分：控制平面与数据平面。当前流行的开源服务网格 Istio 和 Linkerd 都是这种构造。
控制平面的特点：
- 不直接解析数据包。
- 与控制平面中的代理通信，下发策略和配置。
- 负责网络行为的可视化。
- 通常提供 API 或者命令行工具可用于配置版本化管理，便于持续集成和部署。
数据平面的特点：
- 通常是按照无状态目标设计的，但实际上为了提高流量转发性能，需要缓存一些数据，因此无状态也是有争议的。
- 直接处理入站和出站数据包，转发、路由、健康检查、负载均衡、认证、鉴权、产生监控数据等。
- 对应用来说透明，即可以做到无感知部署。
到这一步我们大概了解了微服务架构的演进过程，也初步了解Service Mesh技术比较于传统的微服务架构有哪些优势。
从架构演进的角度聊聊Spring Cloud都做了些什么？
Spring Cloud作为一套微服务治理的框架，几乎考虑到了微服务治理的方方面面，之前也写过一些关于Spring Cloud文章，主要偏重各组件的使用，本次分享主要解答这两个问题：Spring Cloud在微服务的架构中都做了哪些事情？Spring Cloud提供的这些功能对微服务的架构提供了怎样的便利？
这也是我写Spring Cloud三部曲的最后一篇文章，前两面篇内容如下：
我们先来简单回顾一下，我们以往互联网架构的发展情况：
传统架构发展史
单体架构
单体架构在小微企业比较常见，典型代表就是一个应用、一个数据库、一个web容器就可以跑起来，比如我们开发的开源软件云收藏，就是标准的单体架构。
在两种情况下可能会选择单体架构：一是在企业发展的初期，为了保证快速上线，采用此种方案较为简单灵活；二是传统企业中垂直度较高，访问压力较小的业务。在这种模式下对技术要求较低，方便各层次开发人员接手，也能满足客户需求。
下面是单体架构的架构图：
在单体架构中，技术选型非常灵活，优先满足快速上线的要求，也便于快速跟进市场。
垂直架构
在单体架构发展一段时间后，公司的业务模式得到了认可，交易量也慢慢的大起来，这时候有些企业为了应对更大的流量，就会对原有的业务进行拆分，比如说：后台系统、前端系统、交易系统等。
在这一阶段往往会将系统分为不同的层级，每个层级有对应的职责，UI层负责和用户进行交互、业务逻辑层负责具体的业务功能、数据库层负责和上层进行数据交换和存储。
下面是垂直架构的架构图：
在这个阶段SSH（struts+spring+hibernate）是项目的关键技术，Struts负责web层逻辑控制、Spring负责业务层管理Bean、Hibernate负责数据库操作进行封装，持久化数据。
### 服务化架构
如果公司进一步的做大，垂直子系统会变的越来越多，系统和系统之间的调用关系呈指数上升的趋势。在这样的背景下，很多公司都会考虑服务的SOA化。SOA代表面向服务的架构，将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。
SOA服务化的优点是，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。
服务化架构是一套松耦合的架构，服务的拆分原则是服务内部高内聚，服务之间低耦合。
下面是服务化架构图：
在这个阶段可以使用WebService或者dubbo来服务治理。
我们发现从单体架构到服务化架构，应用数量都在不断的增加，慢慢的下沉的就成了基础组建，上浮的就成为业务系统。从上述也可以看出架构的本质就是不断的拆分重构：分的过程是把系统拆分为各个子系统/模块/组件，拆的时候，首先要解决每个组件的定位问题，然后才能划分彼此的边界，实现合理的拆分。合就是根据最终要求，把各个分离的组件有机整合在一起。拆分的结果使开发人员能够做到业务聚焦、技能聚焦，实现开发敏捷，合的结果是系统变得柔性，可以因需而变，实现业务敏捷。
SOA和微服务架构
SOA和微服务的区别
其实服务化架构已经可以解决大部分企业的需求了，那么我们为什么要研究微服务呢？先说说它们的区别；
- 微服务架构强调业务系统需要彻底的组件化和服务化，一个组件就是一个产品，可以独立对外提供服务
- 微服务不再强调传统SOA架构里面比较重的ESB企业服务总线
- 微服务强调每个微服务都有自己独立的运行空间，包括数据库资源。
- 微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
- 微服务的切分粒度会更小
总结:微服务架构是 SOA 架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。
### 为什么考虑Spring Cloud
- Spring Cloud来源于Spring，质量、稳定性、持续性都可以得到保证
- Spirng Cloud天然支持Spring Boot，更加便于业务落地。
- Spring Cloud发展非常的快，从16年开始接触的时候相关组件版本为1.x，到现在将要发布2.x系列
- Spring Cloud是Java领域最适合做微服务的框架。
- 相比于其它框架,Spring Cloud对微服务周边环境的支持力度最大。
- 对于中小企业来讲，使用门槛较低。
Spring Cloud 是微服务架构的最佳落地方案
它的特性
以下为Spring Cloud的核心特性：
- 分布式/版本化配置
- 服务注册和发现
- 路由
- 服务和服务之间的调用
- 负载均衡
- 断路器
- 分布式消息传递
这些特性都是由不同的组件来完成，在架构的演进过程中扮演着重要的角色，接下来我们一起看看。
微服务架构
Spring Cloud解决的第一个问题就是：服务与服务之间的解耦。很多公司在业务高速发展的时候，服务组件也会相应的不断增加。服务和服务之间有着复杂的相互调用关系，经常有服务A调用服务B，服务B调用服务C和服务D ...，随着服务化组件的不断增多，服务之间的调用关系成指数级别的增长，极端情况下就如下图所示：
这样最容易导致的情况就是牵一发而动全身。经常出现由于某个服务更新而没有通知到其它服务，导致上线后惨案频发。这时候就应该进行服务治理，将服务之间的直接依赖转化为服务对服务中心的依赖。Spring Cloud 核心组件Eureka就是解决这类问题。
Eureka
Eureka是Netflix开源的一款提供服务注册和发现的产品，它提供了完整的Service Registry和Service Discovery实现。也是Spring Cloud体系中最重要最核心的组件之一。
用大白话讲，Eureka就是一个服务中心，将所有的可以提供的服务都注册到它这里来管理，其它各调用者需要的时候去注册中心获取，然后再进行调用，避免了服务之间的直接调用，方便后续的水平扩展、故障转移等。如下图：
当然服务中心这么重要的组件一但挂掉将会影响全部服务，因此需要搭建Eureka集群来保持高可用性，生产中建议最少两台。随着系统的流量不断增加，需要根据情况来扩展某个服务，Eureka内部已经提供均衡负载的功能，只需要增加相应的服务端实例既可。那么在系统的运行期间某个实例挂了怎么办？Eureka内容有一个心跳检测机制，如果某个实例在规定的时间内没有进行通讯则会自动被剔除掉，避免了某个实例挂掉而影响服务。
因此使用了Eureka就自动具有了注册中心、负载均衡、故障转移的功能。如果想对Eureka进一步了解可以参考这篇文章：注册中心Eureka
Hystrix
在微服务架构中通常会有多个服务层调用，基础服务的故障可能会导致级联故障，进而造成整个系统不可用的情况，这种现象被称为服务雪崩效应。服务雪崩效应是一种因“服务提供者”的不可用导致“服务消费者”的不可用,并将不可用逐渐放大的过程。
如下图所示：A作为服务提供者，B为A的服务消费者，C和D是B的服务消费者。A不可用引起了B的不可用，并将不可用像滚雪球一样放大到C和D时，雪崩效应就形成了。
在这种情况下就需要整个服务机构具有故障隔离的功能，避免某一个服务挂掉影响全局。在Spring Cloud 中Hystrix组件就扮演这个角色。
Hystrix会在某个服务连续调用N次不响应的情况下，立即通知调用端调用失败，避免调用端持续等待而影响了整体服务。Hystrix间隔时间会再次检查此服务，如果服务恢复将继续提供服务。
继续了解Hystrix可以参考：熔断器Hystrix
Hystrix Dashboard和Turbine
当熔断发生的时候需要迅速的响应来解决问题，避免故障进一步扩散，那么对熔断的监控就变得非常重要。熔断的监控现在有两款工具：Hystrix-dashboard和Turbine
Hystrix-dashboard是一款针对Hystrix进行实时监控的工具，通过Hystrix Dashboard我们可以直观地看到各Hystrix Command的请求响应时间, 请求成功率等数据。但是只使用Hystrix Dashboard的话, 你只能看到单个应用内的服务信息, 这明显不够. 我们需要一个工具能让我们汇总系统内多个服务的数据并显示到Hystrix Dashboard上, 这个工具就是Turbine.
监控的效果图如下：
想了解具体都监控了哪些指标，以及如何监控可以参考这篇文章：熔断监控Hystrix Dashboard和Turbine
配置中心
随着微服务不断的增多，每个微服务都有自己对应的配置文件。在研发过程中有测试环境、UAT环境、生产环境，因此每个微服务又对应至少三个不同环境的配置文件。这么多的配置文件，如果需要修改某个公共服务的配置信息，如：缓存、数据库等，难免会产生混乱，这个时候就需要引入Spring Cloud另外一个组件：Spring Cloud Config。
Spring Cloud Config
Spring Cloud Config是一个解决分布式系统的配置管理方案。它包含了Client和Server两个部分，Server提供配置文件的存储、以接口的形式将配置文件的内容提供出去，Client通过接口获取数据、并依据此数据初始化自己的应用。
其实就是Server端将所有的配置文件服务化，需要配置文件的服务实例去Config Server获取对应的数据。将所有的配置文件统一整理，避免了配置文件碎片化。配置中心git实例参考：配置中心git示例；
如果服务运行期间改变配置文件，服务是不会得到最新的配置信息，需要解决这个问题就需要引入Refresh。可以在服务的运行期间重新加载配置文件，具体可以参考这篇文章：配置中心svn示例和refresh
当所有的配置文件都存储在配置中心的时候，配置中心就成为了一个非常重要的组件。如果配置中心出现问题将会导致灾难性的后果，因此在生产中建议对配置中心做集群，来支持配置中心高可用性。具体参考：配置中心服务化和高可用
Spring Cloud Bus
上面的Refresh方案虽然可以解决单个微服务运行期间重载配置信息的问题，但是在真正的实践生产中，可能会有N多的服务需要更新配置，如果每次依靠手动Refresh将是一个巨大的工作量，这时候Spring Cloud提出了另外一个解决方案：Spring Cloud Bus
Spring Cloud Bus通过轻量消息代理连接各个分布的节点。这会用在广播状态的变化（例如配置变化）或者其它的消息指令中。Spring Cloud Bus的一个核心思想是通过分布式的启动器对Spring Boot应用进行扩展，也可以用来建立一个或多个应用之间的通信频道。目前唯一实现的方式是用AMQP消息代理作为通道。
Spring Cloud Bus是轻量级的通讯组件，也可以用在其它类似的场景中。有了Spring Cloud Bus之后，当我们改变配置文件提交到版本库中时，会自动的触发对应实例的Refresh，具体的工作流程如下：
也可以参考这篇文章来了解：配置中心和消息总线
服务网关
在微服务架构模式下，后端服务的实例数一般是动态的，对于客户端而言很难发现动态改变的服务实例的访问地址信息。因此在基于微服务的项目中为了简化前端的调用逻辑，通常会引入API Gateway作为轻量级网关，同时API Gateway中也会实现相关的认证逻辑从而简化内部服务之间相互调用的复杂度。
Spring Cloud体系中支持API Gateway落地的技术就是Zuul。Spring Cloud Zuul路由是微服务架构中不可或缺的一部分，提供动态路由，监控，弹性，安全等的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。
它的具体作用就是服务转发，接收并转发所有内外部的客户端调用。使用Zuul可以作为资源的统一访问入口，同时也可以在网关做一些权限校验等类似的功能。
具体使用参考这篇文章：服务网关zuul
链路跟踪
随着服务的越来越多，对调用链的分析会越来越复杂，如服务之间的调用关系、某个请求对应的调用链、调用之间消费的时间等，对这些信息进行监控就成为一个问题。在实际的使用中我们需要监控服务和服务之间通讯的各项指标，这些数据将是我们改进系统架构的主要依据。因此分布式的链路跟踪就变的非常重要，Spring Cloud也给出了具体的解决方案：Spring Cloud Sleuth和Zipkin
Spring Cloud Sleuth为服务之间调用提供链路追踪。通过Sleuth可以很清楚的了解到一个服务请求经过了哪些服务，每个服务处理花费了多长时间。从而让我们可以很方便的理清各微服务间的调用关系。
Zipkin是Twitter的一个开源项目，允许开发者收集 Twitter 各个服务上的监控数据，并提供查询接口
分布式链路跟踪需要Sleuth+Zipkin结合来实现，具体操作参考这篇文章：分布式链路跟踪(Sleuth)
### 总结
我们从整体上来看一下Spring Cloud各个组件如何来配套使用：
从上图可以看出Spring Cloud各个组件相互配合，合作支持了一套完整的微服务架构。
- 其中Eureka负责服务的注册与发现，很好将各服务连接起来
- Hystrix 负责监控服务之间的调用情况，连续多次失败进行熔断保护。
- Hystrix dashboard,Turbine 负责监控 Hystrix的熔断情况，并给予图形化的展示
- Spring Cloud Config 提供了统一的配置中心服务
- 当配置文件发生变化的时候，Spring Cloud Bus 负责通知各服务去获取最新的配置信息
- 所有对外的请求和服务，我们都通过Zuul来进行转发，起到API网关的作用
- 最后我们使用Sleuth+Zipkin将所有的请求数据记录下来，方便我们进行后续分析
Spring Cloud从设计之初就考虑了绝大多数互联网公司架构演化所需的功能，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。这些功能都是以插拔的形式提供出来，方便我们系统架构演进的过程中，可以合理的选择需要的组件进行集成，从而在架构演进的过程中会更加平滑、顺利。
微服务架构是一种趋势，Spring Cloud提供了标准化的、全站式的技术方案，意义可能会堪比当前Servlet规范的诞生，有效推进服务端软件系统技术水平的进步。
软件架构（二）编程语言的历史
软件架构（四）单体架构(Monolithic Architecture)
一、编程语言发展史-分类篇
要了解架构的历史，作为架构落地的载体，编程语言的历史有必要先了解下。要注意的是，编程语言并不是一种架构的产出物。架构是设计，编程语言是实现落地的工具。从整体大的发展史来看，可以归纳为3种语言史：机器语言、汇编语言、高级语言。如下图所示：
1.1 机器语言
计算机用0和1来表示电路元件的低电平和高电平，这种语言就是机器语言。由于直接和硬件的电路元件物理逻辑耦合，这种编程代码只能在特定的机器上执行。但由于天生的0/1，快速解释特性，运行效率很快。机器语言，也就是第一代编程语言。
1.2 汇编语言
即第二代计算机语言，用一些容易理解和记忆的缩写单词来代替一些特定的指令。汇编语言（Assembly Language）亦称为符号语言。在汇编语言中，用助记符代替机器指令的操作码，用地址符号或标号代替指令或操作数的地址。在不同的设备中，汇编语言对应着不同的机器语言指令集，通过汇编过程转换成机器指令。特定的汇编语言和特定的机器语言指令集是一一对应的，不同平台之间不可直接移植。
汇编语言仍是面向机器的语言，很难从其代码上理解程序设计意图，设计出来的程序不易被移植，故不像其他大多数的高级计算机语言一样被广泛应用。它通常被用在底层，通常是与硬件交互的场合，尤其在嵌入式领域还是占有一席之地。
1.3 高级语言
在编程语言经历了机器语言，汇编语言等更新之后，为了提高程序的复用性和易用性。高度封装一些底层的实现逻辑，高级语言应运而生。典型的代表就是Python、C、Java。根据其生效方式可分为编译型（使用编译器一次编译，单系统多次运行，速度快）、解释型（运行时使用解释器编译，可跨平台，速度慢）。其中解释型的有：Python、Ruby、PHP、JavaScript; 编译型的有：C、C++、Delphi、Golang。Java比较特殊，是先编译，后需要JVM在系统上解释运行。
二、编程语言发展史-风格篇
编程语言也有自己的风格、设计模式。这一节我们从风格发展史来看编程语言。如下图所示：
2.1 非结构化编程
汇编 ~1951
软件开发曾经是一项高深莫测的活动，只发生在世界上很少的地方。那时汇编是最热门的语言，它使用非常底层的“add”“sub”“goto”操作并直接操纵内存地址。创建一个简单的应用程序都很困难，也要花费很长的时间。它需要好几行代码才能实现条件语句，而实现循环就需要更多代码行了...划分和重用代码段的能力是它之后的事情了，所以它的编码风格就是一路到底，代码重用仅限于在单个文件中或多个文件之间复制粘贴代码。
2.2 结构化编程
Algol ~1958
结构化编程出现，引入了代码块、控制结构(if/then/else、case、for、while、do、…)和子例程。然后，我们可以创建更有趣的代码流，更重要的是，我们可以对代码指令进行分组并重用它，尽管有一些限制，比如子例程总是作用于相同的全局变量。可复用性想法第一次落地了。
三种风格/范式：
1.POP（Procedure Oriented Programming）面向过程编程： Pascal ~1970, C ~1972
过程式、函数式编程，诞生于20世纪70年代。这时我们终于拥有了：
- 过程：一组不返回数据的指令；
- 函数：一组返回数据的指令；
- 数据结构：记录，和关联数组类似；
- 模块：可以在其它代码文件中导入的代码文件。
伴随着这些改进，我们有了更好的重用性，因为子例程(过程或函数)可以对不同的数据执行同样的逻辑。我们还可以通过将关联的数据划分在一起编程复杂的数据接口来对领域概念建模。最后，我们迈出了解耦和模块化的第一步，我们可以创建在其他代码文件中重用的代码，还可以创建事件来分离调用方代码和执行逻辑。
2.OOP（Object Oriented Programming）面向对象编程： Simula ~1965, Smalltalk-71 ~1971, C++ ~1980, Erlang ~1986, Perl ~1987,Python ~1991, Ruby ~1993, Delphi, Java, Javascript, PHP ~1995
OOP的思想和理论早在20世纪60年代就开始萌芽了而且在那个年代第一次被Simula 实现了。然而，现在这种编程范式的使用方法却是在20世纪80年代形成的：拥有可见性级别、方法(消息)、对象、类以及包的面向对象编程。核心就是encapsulation封装和modularity模块化。
- 可见性级别 控制一组特定的数据能被哪些代码访问；
- 类 定义/建模领域概念；
- 对象 创建出同样领域概念的不同实例；
- 包 将类划分到一组表示领域概念或功能概念，来共同完成某个任务；
- 方法 从功能性角度来看代表了过程和函数；
3.AOP（Aspect Oriented Programming）面向切面编程： 面向主观编程和面向切面编程在 20 世纪 90 年代横空出世。典型的Python、Java、Php都有相应实现。
面向主观编程：现在不太常见了，这里不展开讲。
面向切面编程：试图通过在“编译”期注入额外的代码来将横切面的关注点从真正的业务逻辑中分离出来。
21世纪web语言爆发
早期其实是没有纯前端语言的，是和后端语言一体化的。慢慢MVC模式风靡后，渐渐进化出了纯前端语言。进入21世纪，前端语言也如雨后春笋般增长起来，典型的有AJax、jQuery、AngularJS、ReactJS、VueJS、HTML5等。
引子
常常，我们会被一堆名字绕晕：架构风格、架构模式、设计风格、设计模式、架构设计。查看维基百科：目前业内也没有明确的理论，但是我们现在可以识别出许多架构模式（Architecture Patterns）或风格（Architecture Styles），它们构成了软件架构师的基本技能。本文就来捋一捋这些词语。
一、名词解释
我们把这几个次拆解开得到4个基础词汇，其中架构和设计是一组，风格和模式是一组。
- 架构：架构专注于可以被多个设计所利用的抽象。
- 设计：设计是建立特定事物的具体计划。架构也是一种设计。专注于架构的设计。架构设计就是这个意思。这也是为啥架构师很多时候是不需要写代码的。理论这一块玩的透透的。
- 风格：某一特定应用领域中系统组织方式的惯用模式。事物的代表性元素特性。
- 模式：指事物的标准样式，是结构主义用语。指用来说明事物结构的主观理性形式。
二、概念剖析
- 1.风格是模式的一种抽象
- 2.架构是设计的一种抽象
如上图所示，风格也是一种模式，架构也是一种设计。架构风格是一种顶级抽象。其次是架构模式，设计模式是最底层实现落地层面的。
- 架构风格是最高抽象级别的应用设计。
- 架构模式是实现架构风格的一种方式。
- 设计风格就是设计中的某些风格，架构风格就是专注于架构设计的风格。
- 架构设计就是专注于架构的设计。
- 设计模式是解决局部问题的方法。GOF95的23种设计模式，是最具认可度的。
三、举例说明
- 单体应用Monolithic application
- 分层Layered
- 事件驱动Event-driven
- 发布订阅Publish-subscribe
- CS架构Client-server
- 面向服务Service-oriented
- MVC：常见于后端架构。springbootMVC
- MVVM：常见于前端架构。例如国内三大框架之一的vue.js
- 从小（模块\功能）到大（系统）的设计中体现出来的一种style。上面列的架构风格都可以说是设计风格。
- springCloud架构设计。包含gateway、feign、eureka/nacos、ribbon、hytrix、某DB/缓存等一套通用解决方案。这也是架构师必会技能之一：架构设计图。
- 单例模式
- 工厂模式
- 策略模式
一、软件发展趋势
- 模块化（Modular）
例如，JAVA中默认级别意味着类只在其package中可见，而public意味着类在其package内外都可见。一直到JDK9，模块化直接作为重大特性发布。其实就是将JDK中类，模块化拆分。
- 组件化（Componentized）
组件是另一种模块化风格。组件是按照业务领域划分的模块。理想情况下，它们是可以组成应用的独立的“应用程序”。微服务可以理解为应用的组件。
组件化，也是早在 20 世纪 60 年代末就已经存在了。
二、现代单体架构
2.1 单体架构介绍
相信大部分程序员接触的第一个程序都是：一个工程中，一个文件，打印 "Hello World ! "。当初的喜悦仿若还在身边。实际上这就是一个单体架构。
如今，单体架构意味着代码被部署并作为单个节点上的单个进程运行。有可能进行初步的模块化拆分（类级别），但由于整个工程一起打包部署，所以还是一个组件。如下图所示：
2.2 单体架构缺点
- 领域组件无法独立可伸缩：例如订单模块访问频率最高无法做到单独给订单模块独立水平拓展。
- 不同的领域组件，适合用不同编程语言实现时，无法拆开组件实现；
- 各组件无法做到单独发版，只能一起发布。拖慢研发节奏。
Anti-pattern: 大泥球（Big Ball of Mud）/ 意大利面（Spaghetti）架构
单体架构可能会演变成“大泥球”，又名意大利面条架构。其中包的结构和关系不显式，结构内聚和封装程序低，依赖不遵循规则，很难进行更改和重构。系统是不透明的，粘性的，脆弱的和僵硬的，就像一个大的泥球!
2.3 解决方案
将单体架构按照面向服务的架构风格拆分成不同的应用程序。即服务拆分，微服务化。国内15年开始火，一直延续至今。但很多传统企业内部仍存在很多单体架构服务，这无所谓好坏，只有合适否。有时候，能很好的支撑运行就够了，毕竟改造是需要成本的。
零几年最早接触编程时，写的课程设计就是MVC架构，这就是一种典型的分层架构。
一、分层概念
分层是一种常见的根据系统中的角色/职责拆分和组织代码单元的常规实践。注：本文说的不单指后端架构，而是整个软件的分层架构，包含前端、后端、数据库。
在一个分层系统中，每一层：
- 依赖它之下的层；
- 和它之上的层无关，对使用(依赖)它的层次无感知。
在分层架构中，分层可以访问它之下的任何分层。
二、分层历史
2.1 单层架构--20 世纪 60 年代和 70 年代
当时的应用程序和今天的应用程序截然不同。那时还没有 GUI。所有的应用程序要通过命令行使用，显示在一个哑终端里，它们实际上是单层的应用程序。如下图所示
2.2 三层架构--20 世纪 80 年代和 90 年代
在 20 世纪 80 年代，企业应用出现了，在公司里有多个用户开始使用桌面电脑通过网络访问应用。
这时它们多半分成三层：
- 用户界面(展现)：用户界面就是网页、命令行或者原生桌面应用；
- 例如：作为(富)客户端的 Windows 应用，普通用户在桌面电脑上使用，和服务器器通信才能完成工作。客户端负责应用的流程和用户输入的校验；
- 业务逻辑(领域)：应用之所以存在的逻辑；
- 例如：应用服务器，包含业务逻辑并从原生客户端接收请求，采取行动并将数据保存到数据存储；
- 数据源：数据的持久化机制(数据库)，或者是和其它应用之间的通信。
- 例如：数据库服务器，应用服务器用它来完成数据持久化。
这实际上是一种 两层 应用，客户端是一个用为应用界面的富客户端应用程序，而业务逻辑和数据源放在服务器。
90年代后期，发展出真三层架构：
- 原生浏览器应用程序：渲染和运行用户界面，向服务器应用发送请求；
- 应用服务器：包括了展现层、应用层、领域层和持久化层；
- 数据库服务器：应用服务器用它来完成数据的持久化。
这就是三层架构模式，也叫 N 层架构。它是可伸缩的解决方案，尽管用户界面是在客户端浏览器中渲染和运行，但由于用户界面存放于服务器上并在服务器上编译，它“解决了客户端的更新问题”。
说实话这种架构，在国内很少用到。国内到2010年，主流都还在玩MVC。
2.3 多层架构--2003年之后DDD领域驱动设计
-
用户界面
负责绘制用户和应用交互的界面，并将用户输入转换成应用的命令。值得注意的是，“用户”可以是人类也可以是其它应用。它和 Ivar Jacobson 的 EBI 架构(后面其它文章会介绍更多细节)中的边界对象不谋而合；
-
应用层
指挥领域对象完成用户要求的任务。它不包括业务逻辑。它和 Ivar Jacobson 的 EBI 架构中的交互器对象对应，唯一不同的是 Jacobson 的交互器可以是任意和界面或实体无关的对象；
-
领域层
这一层包含了所有的业务逻辑、实体、事件或者其它任何包含业务逻辑的对象类型。显然它和 EBI 中的实体对象类型相对应。这是系统的心脏；
-
基础设施
支撑上面所有层次的技术能力，如持久化机制和消息机制。
很奇怪的是，03年风靡国外的DDD，竟然在21年才开始风靡。炒了一锅冷菜。DDD理论很好，但落地是有一定难度的，具体落地可参考博客：DDD领域驱动设计落地实践（十分钟看完，半小时落地）
2.4 反模式：千层面模式
当我们过分严格遵守分层架构时，容易出现“反模式”。过度的抽象并不利于使用。记住：架构是用来用的，如果成了累赘，不要这种架构也罢。
千层面架构常常说的就是分层架构的反模式。以下这些情况发会出现：
- 热衷于创建完美的系统导致项目过度抽象；
- 小更新也会波及应用的方方面面，牵一发动全身，增强依赖性，提升了变动的风险。
- 层次太多，增加了整个系统的复杂性；
- 物理层次太多，不但增加了整个系统的复杂性，还降低了系统的性能；
- 按照UI界面切割，垂直分层来组织我们的单体，破坏了领域概念的模块化和封装。
一、引子
一个系统可能由很多子系统组成。各子系统内部高度内聚，子系统之间低耦合。子系统关注自己的职责。实现: 职责分离，关注点分离。----MVC架构早期就是为了分离视图、模型而诞生的。
注：很多地方说MVC是一种设计模式，博主认为，精确来说MVC是一种架构模式（软件架构（三）名词解释：架构、设计、风格、模式），一种通用设计方案，发展至今，已不局限于前端或后端。例如springMVC就是其中一种落地实践。
二、MVC的发展史
MVC有很多变种，这里列出对现在行业影响最大的几种，逐一说明。老司机可以直接跳到第三节。
2.1 MVC（Model-View-Controller）
Trygve Reenskaug 于1979 年提出了 MVC 模式，来分离关注点，将 UI 和业务逻辑隔离。
MVC 模式将代码拆分成了三个概念单元：
- Model (模型)：代表业务逻辑 ；
- View (视图)：代表 UI 控件，按钮、文本框等等；
- Controller(控制器)：在视图和模型之间居中协调 ，这意味着:
- 它决定显示哪些视图以及哪些数据；
- 它将用户操作(例如点击按钮)转换成业务逻辑。
最初的 MVC 模式还有其它一些需要了解的的重要概念：
- View 直接使用 Model 数据对象来展示数据；
- 当 Model 发生变化时，会触发一个事件立即更新 View(记住，1979年还没有 HTTP)；
- 每一个 View 通常只关联一个 Controller；
- 每个界面可以包含多对 View 和 Controller；
- 每个Controller 可以对应多个 View。
2.2 MVP（Model-View-Presenter）
1996 年，IBM 的子公司 Taligent 公开了他们基于 MVC 的 模式 MVP。其思想是将 Model 对 UI 的关注更彻底地分离：
- View 是被动的，对 Model 无感知；
- 专注于轻量 Controller(Presenter)，它们不包含任何业务逻辑，只是简单地调用命令/查询模型，将原始数据传递给 View；
- 数据的变化不会直接触发 View 的更新：它始终要通过 Presenter，由 Presenter 来更新 View。这样在更新视图之前 Controller(Presenter) 还可以执行一些和展现相关的额外逻辑。例如，同时更新另一些数据，它们和数据库中发生变化的数据有关；
- 每个 View 对应一个 Presenter。
这更接近我所见到的现在的请求/响应范式：数据流始终要经过 Controller/Presenter。不过，Presenter 仍然不会主动更新视图，它始终需要执行一次新的请求才能让变化可见。
MVP 中的 Presenter 又被称为 Supervisor Controller监督控制器。
2.3 MVVM（Model-View-ViewModel）
- ViewModel 和 View 一 一对应；
- 将 View 中的逻辑转移到 ViewModel 来简化 View；
- View 使用的数据和 ViewModel 中的数据一 一对应；
- 将 ViewModel 中的数据绑定到 View 中的数据上，这样 ViewModel 中数据的变化会立即体现在 View 上。
2.4 MVPVM(Model-View-Presenter-ViewModel)
MVPVM中， View Model 是 Martin Fowler 在 2004 年提出的 Presentation Model,。
-
Model
一组包含业务逻辑和用例的类。
-
View
一个模板，模板引擎用它来生成 HTML；
-
ViewModel(又叫做 Presentation Model)
从查询中接收(或者从 Model 实体中提取)原始数据，持有这些模板会用到的数据。它还要封装复杂的展现逻辑，来简化Model。这样我们才能将 View 和 Model 完全隔离开：
- Model 中的变化(比如实体结构的变化)会上升并影响 ViewModel，但不会影响Model；
- 复杂的展现逻辑被封装到了 ViewModel 之中，因此不会被泄露到领域(DDD领域设计的domain)之中；
- Model的依赖变得很清晰，因为它们必须在 ViewModel 中设置。
-
Presenter
接收 HTTP 请求，触发命令或查询，使用查询返回的数据、ViewModel、模板和模板引擎生成 HTML 并将它返回给客户端。所有 View 的交互都要经过 Presenter。
三、总结
我们对比MVC、MVP、MVVM、MVPVM的变种升级过程，可以更好的了解架构的历史变迁。
快速区分几种架构：
- MVC：初步分离Model、View。
- MVP：Controller转变为Presenter模型和视图彻底分离。
- MVVM：废弃控制器层。增加ViewModel，实现Model和View的双向驱动。
- MVPVM：保留Presenter做页面交互，新增ViewModel给View做数据接收和展示。
浙公网安备 33010602011771号