微服务架构简介及AWS Lambda的应用

版权声明:本文由神州数码云基地团队整理撰写，若转载请注明出处。

作者：Hiro，神州数码云基地PM。

在IT开发领域，微服务架构提出可以说改变了应用程序的开发架构方式，能够为开发人员带来实质性的好处，并给IT开发架构造成显著的影响。而AWS则为微服务开发方式提供了完备的解决方案平台，为微服务架构提供了一系列平台工具，其中与微服务联系最为紧密的一个计算服务就是：Lambda。

单体架构的困境

传统的单体架构方式下，应用原有的表现层、逻辑层、数据层的3层应用架构的每一个大层面都有大量的逻辑封装，最终导致这种架构的应用程序在前期开发和后期的维护和管理方面都非常费时费力，且漫长的开发周期也给技术和需求带来落后的风险，并进一步陷入应用升级和优化难度大的困境，非常不利于应用和系统的长期更新和维护。

另外，单体架构下的开发团队可能会基于同一个代码库进行开发工作，甚至修改相同部分的代码，这就导致在技术管理上很难发现开发成员具体做了哪些工作，如果开发团队是彼此独立的，团队之间也很难意识到自己团队的工作内容是否与其他团队的工作内容存在重复或者功能上的排斥部分，最终导致整体项目代码存在代码冲突，影响项目代码质量和应用程序的可用性，必然存在项目延期的风险。

关于微服务架构

鉴于单体架构的发展困境，微服务的开发架构得以被广大开发人员接受和倡导，微服务的开发模式在将每一个单一大层面的应用进行拆分，将其变成独立的小应用，这里的小应用就可以看作是彼此独立的微服务，每一个小应用都能够独立部署，彼此之间通过Http或者API等轻量级的交互方式进行功能交互，进而构成完整的系统，由于应用之间的独立性和服务之间的松耦合，故而应用可以采用不同的开发语言、开发技术以及不同数据存储机制来分别开发不同的服务组件，在后期维护或者更新的时候，独立的小应用可以单独进行维护或者升级，解决技术债务的工作量和系统升级的复杂性就会降低。

同时开发架构的改变必然导致开发团队的组织结构的调整，对于大型项目来说，彼此的微服务应用对应的开发团队也可以是独立的，多个独立微服务应用对应的独立的开发团队可以基于彼此独立的微服务应用的代码仓库进行开发工作，团队之间互不影响，分工更加明确，各个模块功能独立开发、独立部署，在系统层面可以达到分批上线的目的。

 

但是微服务的出现并非偶然，技术发展导致的技术债务日积月累、系统升级的工作量和复杂性增加、开发周期拉长导致的系统稳定性风险加大以及工程理念和敏捷开发等开发思想的共同作用下，在各种传统架构的基础上以及系统拆分的思维火花中，微服务架构逐步得以发展和完善，所以微服务架构仍然是如下这些传统开发架构的基础上发展而来，具体包括：

1. Client/Server架构：客户机和服务器分离架构，充分利用客户机和服务器硬件环境的优势来分别处理合适的任务；

2. Blackboard架构：独立的应用程序共同完成同一个数据的处理；

3. Peer-To-Peer架构：运行程序的终端实体同时承担用户端和服务端直接通讯；

4. Component Based架构：在基础组件的支持下，快速复用已有组件构建应用软件；

5. Service Oriented 架构：微服务架构的前身——SOA架构，将应用程序的功能服务化提供给终端用户或者其他服务；

微服务架构正是在上述传统架构的基础上，受到敏捷开发、持续集成/交付、虚拟化部署及DevOps等软件设计领域思想的影响而产生，因而采用微服务架构进行开发的系统非常适合采用敏捷方法进行管理，在部署上采用持续集成/交付进行频繁的部署，在微服务团队管理方面，面向DevOps流程实践组件小巧的开发团队。

总体来说，被微服务化的应用程序具备如下几个典型特征：

1. 功能组件化：微服务化的软件被拆分为多个服务组件，业务功能也以服务组件的形式模块化，每一个服务为一个具有单一功能的组件，每一个服务的责任单一；
2. 模块轻量化：应用程序的每一个服务只专注与某一个功能，并将其优化到最佳，也非常方便将其逐步优化至最佳状态，优化迭代的成本和工作量也相对较小；
3. 部署独立化：每一个服务模块可以独立运行和部署，并且不受部署目标的限制，可以独立在不同的地方进行部署，并独立运行；
4. 通信轻量化：彼此独立部署后的服务模块可以独立运行，彼此之间可以通过http及Api等较为轻量化的通讯方式进行服务和功能交互；
5. 耦合松散化：微服务模块独立部署和运行，彼此之间影响较小，呈现独立的姿态，只需要关注服务本身，对其他服务的依赖较小，单一服务的故障也不会影响到其他服务；
6. 技术混合化：独立的服务可以独立开发，可以依据服务组件开发团队，团队之间的技术不受限制，可独立采用不同的技术或者语言进行开发；

基于上述典型特征，微服务架构显然也有着诸多优势，微服务的应用也不仅限于新软件的开发项目，同样可以在历史应用程序的架构改造上面，总体来讲，微服务架构的优势有如下这些：

1. 构建自动化：微服务架构非常适合持续集成/持续部署（CI/CD）的实践，由于服务的微型化，构建过程较庞大的单体架构要快得多，因此在实践单个应用的持续集成后应用程序可自动构建，因此开发人员无需手动编写代码处理构建细节；
2. 交付快捷化：持续部署/交付对交付速度要求较高，但是微服务可以做到，单体架构由于其自身的复杂性和庞大性，应用部署的交付速度难以提升，其对基础设施、环境和测试的要求都较高，而微服务则化解了单体架构的复杂性和庞大性，交付的速度就能够得到快速提升；
3. 拓展简易化：系统层面的迭代或者功能拓展可以被分解为微服务层面的拓展或者迭代，从底层基础的微服务上进行拓展，单个组件也可以进行自由横向的拓展来满足功能需求，较之单体架构，工作量和复杂度都要小得多；
4. 故障隔离化：独立部署的应用能够降低应用崩溃造成的影响，并将影响转移到应用的每个独立的子应用，因此任何组件的崩溃都只会降低的功能的全面性而不会影响整个应用程序的运行；
5. 转型快捷化：微服务转型时可以从重建的组件中使用服务，应用的功能不需要重新开始构建，对转型来说更加快捷方便；
6. 技术自由化：开发团队可以自由选择开发技术、框架和工具，并能够独立构建、部署和维护服务，进而实现邠所需业务的外包；
7. 管理去中心化：在传统应用的部署过程中必须有一个基础服务作为软件的核心，其他服务在此基础上，而微服务架构中应用可以独立部署，分批上线，彼此互不影响，没有一个中心化的基础服务；
8. 开发并行化：由于服务应用之间的独立性和松耦合，在开发之前只要约定好各服务之间的接口协议，开发人员就可以并行进行开发，只要协议不变，服务之间就是无感知状态，服务模块之间的耦合性进而降低，并行开发则能够快速构建服务系统。

尽管微服务有如上这么多好处，但是微服务也并不是完美无缺的，微服务应用的架构也存在一定的挑战，具体如下：

1. 系统复杂性增加：尽管微服务很容易被理解和被管理，但是庞大的应用系统还是由各种活动的微服务组件构成，组件越多，彼此之间的依赖就越高，这就增加的应用程序的复杂性，并降低了系统的内聚性，这样的结果就是以前一句Sql就能完成的接口现在需要调整好几个相关的服务。
2. 运维的难度增加：后期运维的过程中下游的依赖关系难以追踪，一旦下游依赖关系发生故障，就很有可能因此而造成整个应用系统的故障，同时变更及升级的管理的难度加大，下游服务间的依赖过于复杂，加上服务数量的增加和服务本身的无状态给服务监控和治理增加了难度和复杂度；
3. 网络延时增加：微服务可能会造成网络层面的延时，由于你不得不从每一个独立的微服务中获取服务，所以这就需要额外的管理和时间成本；
4. 协调管理难度增加：由于服务的独立性，开发和测试只能通过模拟请求报文或者直接连接的方式来调用服务提供方的接口，从而增加了不同团队之间的沟通和协调成本；
5. 第三方微服务的局限性：第三方服务可能随时独立地更改API，这就可能造成引用第三方微服务的应用程序崩溃，这是来自第三方的隐患；
6. 系统脆弱易攻击：微服务会增加软件程序的脆弱性，微服务架构允许在构建应用程序的时候使用多种操作系统和开发语言，因此有可能成为入侵者的攻击目标。

这些潜在的问题就是为什么在采用微服务架构的时候需要仔细规划，开发团队必须十分仔细、慎重地分解软件的功能和彼此之间的依赖项，以及对微服务进行恰当地调整的原因所在。

面向微服务的组织调整

康威定律中描述道：“任何设计系统的组织……必然会产生以下设计结果，即其结构就是该组织沟通结构的写照。”产品是团队的产物，有什么样的开发团队就有什么样的产品，除了团队技术水平，组织架构也会直接反映在团队的产品中，所以传统架构的团队开发自然不适合开发微服务架构的产品。

在传统模式下一个产品系统的开发团队可能会分为多个专一职能的团队，共同对整个单体架构的产品功能负责，这样的团队可能包含如下这些专一职能的团队：产品团队、用户体验团队、开发团队、测试团队、数据库团队、系统管理团队等职能团队，传统的单体结构采用这种组织架构无疑是合适的，也是比较好的，但是产品系统采用微服务架构的话就会不太合适，团队间的沟通成本太高，不利于协作工作，因为每一个微服务应用都需要配备这样一个完备的职能团队，人力成本也非常大。

因此，在传统团队面向微服务转型的时候，需要对组织进行调整，正对微服务的各个应用组件独立的微小而高效的团队，每一个小团队专门负责该服务，独立负责应用的管理和开发工作。前文有提到过微服务架构的一大优势就是构建自动化和交付快捷化，微服务架构下服务应用的轻量化非常适合DevOps实践的应用，其跟DevOps也有着非常紧密的联系，微服务自身也是传统架构在DevOps实践思想指导下的结合和演化而来，所以这里的面向微服务架构的组织调整实际就是开发团队的DevOps的实践和转型。

 

AWS的微服务应用

诸如AWS等云供应商为开发者提供了很多可以解决微服务架构缺陷相关问题的工具，并且和在AWS和微服务方面经验丰富的开发者合作可以确保在项目能够完美地实践微服务架构，可以说AWS是最完整的微服务平台，为微服务开发方式提供了完备的解决方案。

其中Lambda是AWS云服务中与微服务关系最为紧密的一个计算服务，是AWS提供的一种无服务器计算服务，也是AWS中实现微服务的最佳方式，在Lambda中，用户只需要实现服务的逻辑即可，AWS为用户提供服务运行的环境，当有一个触发事件发生的时候，Lambda会在事件池中运行一个事件来触发函数服务，Lambda响应的触发事件的种类有很多种，通常由S3储存事件、DynamoDB Streams事件、Kinesis（事件流）事件以及定制化事件等，Lambda作为服务的提供方，通常用API Gateway来为终端提供微服务的访问能力，Lambda进而对API Gateway的请求做出相应以提供计算服务。

除此之外，AWS中基于Container的服务ECS（Elastic Container Service）也是可以提供计算能力的服务之一，但是Lamdba较之更加灵活而简单。AWS基础资源的拓展性及资源利用性如下所示：

AWS中使用Lambda实现微服务的典型架构图如下所示：

传送门：

使用AWS Devops工具结合ECS实现自动化Docker容器部署

AWS、Azure、Github的DevOps支持工具分析

C#实战踩坑指南1：一个关键字引发的血案