微服务架构系列一：关键技术与原理研究

导语：人不为己，天诛地灭这个成语中的“为”念作wéi，阳平二声，是“修养，修为”的意思。成语的意思是：如果人不修身，那么就会为天地所不容。本意并不是经常被很多人曲解的人如果不为自己着想，那么就会为天地所不容。以此为引，本文本着Stay Hungry, Stay Foolish的精神，利用闲暇时间，抛开平时工作中的常用组件，追本溯源，尽可能从源头去思考、分析、发现，结合过去的一些经验做了一点微服务架构相关的调研和简单实践，以能在日常工作中对内部组件更好的理解和使用。由于时间和水平有限，文中一些地方难免有纰漏，欢迎大家留言指正和补充建议，衷心感谢。

前言

系统架构设计是系统构建过程中的非常关键的一部分，决定着系统的稳定性、鲁棒性、扩展性等一系列问题，定义了在系统内部，如何根据技术、业务和组织及可扩展性、可维护性和灵活性等一系列因素，把系统划分成不同的组成部件，并使这些部件相互协作为用户提供某种特定的服务。不过伴随着业务的不断发展，功能的持续增加，传统单块架构对应的沟通、管理、协调等成本越来越高，出现了维护成本增加，交付周期长，新人培养久，技术选型成本高，水平和垂直扩展性差，组建全功能团队难等一系列问题。为解决传统系统架构面临的问题，随着领域驱动设计，持续交付技术，虚拟化技术，小型自治团队组建，基础设施智能化自动化，大型集群系统设计等技术和实践的发展，微服务应运而生。微服务作为一种分布式系统解决方案，聚焦细粒度服务使用的推动。不同的微服务协同工作，每个服务都有自己的生命周期。由于微服务主要围绕业务领域构建模型，而且整合了过去十多年来的新概念和新技术，因此可以避免由传统的分层架构引发的很多问题及陷阱，具有很大的研究价值和实用意义。

本文通过阅读众多相关文献和专著以及相关技术官方网站的在线文档和开源社区优秀博客，从微服务的单一职责、自治性、领域驱动设计等设计原则开始，研究了其相关技术栈，包括容器虚拟化技术，服务发现技术，通信机制技术，持续集成、交付、部署等。其中较为详细的介绍了提供高可用分布式键值存储及服务发现等功能的Etcd的使用及原理，RESTful API、Thrift RPC、gRPC等同步通信技术的对比以及异步通信中高性能分布式消息队列Kafka的使用和原理等。 在以上研究基础上，重点调研了谷歌能够管理容器化应用和服务及进行自动化扩缩容的开源框架Kubernetes的架构原理，包括服务API，控制管理器，调度器，Kubelet，Kube-Proxy，DNS等核心技术以及GUI，日志与监控等组件，并重点分析了框架的安全依赖，包括认证，授权，准入控制等相关技术。并在云上和本机搭建了Kubernetes高可用集群及相关组件，作为微服务实践和密码强度评测实验的基础架构。

依托Kubernetes集群，本文进行了以基于机器学习的密码强度检测为核心的微服务实践，之所以选择这个实验载体而没有选择常见的支付、评论、画像、push等业务载体是因为之前应用微服务架构的实际生产环境应用场景是在“K歌厅”（一种像电话亭一样的微型KTV包厢，目前市面主要有三家：全民k歌自助店，友唱·全民k歌，咪哒唱吧minik）大致流程是用户通过公众号或小程序扫VOD二维码码进行支付，web前端经过SLB调用前端机PHP“胶水”层，胶水层经过IngressController调用K8S集群中的golang相关微服务，包括支付，开房，PUSH，短信等相关微服务，其中支付服务会把结果写到kafka，消费者服务消费后通过长连接微服务把相关结果再推送给VOD，这个场景由于多了VOD（K歌厅终端相关设备，除了音响相关设备，一般由一块显示屏，一个点歌屏组成，有的还有广告屏+提示板）较普通移动应用——人和APP及服务端交互相比相对复杂，不太好表述，最终抽象出关于密码强度评测的一个简单事例。同时因为在云计算和大数据迅猛发展的今天，机器学习被越来越多的应用到各行各业中，但是它的微服务化工程落地相对少见和困难，同时密码强度评测技术作为安全领域的重要组成部分也亟需使用机器学习等新技术去更新换代，而这些技术背后的底层服务和业务服务也将随着微服务的发展，业务本身规模的发展以及组织架构的需要而逐步微服务化，从而相辅相成发挥更大的效能，以此选例也求有所提高和突破。

绪论

1. 研究背景和意义

系统架构设计阐述了在系统内部，如何根据技术、业务和组织及可扩展性、可维护性和灵活性等一系列因素，把软统划分成不同的组成部件，并使这些部件相互协作为用户提供某种特定的服务的相关技术，是系统构建过程中非常关键的一部分，好的架构决定了系统的稳定性、鲁棒性尤其是可扩展性等一系列问题，这也佐证了为什么系统架构设计一直以来都是IT领域经久不衰的话题之一。

1.1传统架构

 随着面向对象和设计模式的发展，从功能实现及代码组织的角度，依据职责划分产生了经典的MVC框架，MVC模式最早在1979年由Trygve Reenskaug提出[1]，是Xerox PARC（施乐帕罗奥多研究中心）在20世纪下页为程序语言Smalltalk发明的一种软件架构，MVC是模型（Model），视图（View），控制器（Controller）的缩写，其中模型聚焦数据访问及存储，视图聚焦数据显示和用户交互，控制器聚焦业务处理。每一层都有具体的职责和分工，这降低了层与层之间的耦合度，这便是软件架构的经典模式，又被称为三层架构。三层架构将系统进行了逻辑分层，但是在物理上最终会运行在同一进程中，所以三层架构又被称为单块架构。

虽然三层架构解决了代码间调用复杂、职责不清的问题，甚至在一定程度上解决了企业内部根据技能调配人员的难题，而且其易于开发、易于测试、易于部署和易于水平伸缩等特性也提高了生产效率。但是随着应用功能的多样化复杂化及技术团队的不断壮大，其对应的沟通、协调和管理等成本也越来越高，出现了维护成本增加，交付周期长，新人培养久，技术选型成本高，水平和垂直扩展性差，组建全功能团队难等一系列问题。

随着业务的不断发展，功能的持续增加，三层逻辑架构设计中的单块架构已很难满足业务快速变化的要求：一方面，代码的可维护性、可扩展性和灵活性在不断降低；而另一方面，系统的测试成本、构建成本和维护成本又在显著增加。随着项目的不断发展和产品规模的不断扩大，单块架构应用的改造甚至重构势在必行。为解决这些问题，SOA（Service Oriented Architecture，一种面向服务的架构）出现了，顾名思义它有两个核心：一是服务，二是架构。SOA架构中包含多个服务，服务之间通过互相配合来完成一系列功能。一个服务通常以独立的形式存在于操作系统中，服务与服务之间不再通过进程内调用方式进行通信，而是改为网络调用，甚至当服务需要方Client和服务提供方Server都部署在同一机器时，也是通过网络调用完成请求和响应。SOA相对于传统单块架构的优势和特点是服务化，松耦合，灵活的架构，支持敏捷等。

SOA最早由Gartner在1996年提出，2002年12月，Gartner再次提出SOA是“现代应用开发领域中最重要的课题”[2]。不过虽然面向服务的架构SOA的理论和实践方面已经研究了十多年[3]，但是由于给SOA下定义的组织机构太多，没有一个统一的标准，而且加之用SOA概念包装已有或推出各种产品解决方案厂商的一定程度上的误导和其本身的抽象性及广义性，导致在很长一段时间内人们对于SOA都存在着不同的认知和理解。所以尽管大家做了很多努力和尝试，但终究无法在如何做好SOA这件事情上达成一致的方法论。除了不同角色的参与人员很难把它作为一个整体进行统筹外，在实施SOA过程中还会有各种各样的别的问题：比如通信机制及协议的制定，服务粒度的确定和边界的划分，各种中间件的选择等。而且现实问题是现有的SOA解决方案并不能有效的防止服务之间的过度耦合而且很难把应用程序的大小控制在合理的范围内，所以对于单块架构发展到一定规模遇到的问题同样不可避免。

不管是经典三层架构还是面向服务的架构SOA或是从面向资源的ROA还是其它衍生品，在传统架构下，随着产品的发展，软件的迭代，代码间的逻辑会越来越复杂，代码也越来越多，时间久了代码库就会变得非常庞大，以至于在修改逻辑或者增加新功能时想定位在什么地方做修改都很困难。尽管大家都想在巨大的代码库中做到模块化，但实际上模块之间的界限很难确定，而且更不好处理的是，相似功能的代码在代码库中随处可见，使得修改旧逻辑和增加新功能变得更加异常复杂。而且随着组织架构的变大，参与人员的变多，这一问题将会变得更加棘手。

1.2 微服务架构

随着领域驱动设计，按需虚拟化，持续交付，小型自治团队，基础设施自动化，大型集群系统等技术和实践的发展以及为解决传统架构的痛点，微服务应运而生。微服务是一种分布式的系统解决方案，着力推动细粒度的服务的使用，不同的微服务协同工作，每个服务都有自己的生命周期。由于微服务主要围绕业务领域构建模型，所以可以避免由传统的分层架构引发的很多问题。微服务整合了过去十年来的新概念和新技术，因此得以避开许多面喜爱那个服务的架构中的陷阱[4]。

微服务的由来：

2011年5月，在威尼斯附近的软件架构师小组首次提及了“Microservice”一词，以描述参会者中的许多人在近期探索研究的许多架构风格。

2012年3月，来自ThoughtWorks 的James Lewis 在克拉科夫33rd Degree 会议上的[5]中就此做了相关的案例研究报告，几乎同一时间Fred George也做了与之相同的工作。

来自Netflix的Adrian Cockcroft把这种方法称为“细粒度SOA”，并认为这是一套在Web规模下具有开创意义的架构类型。Joe Walnes，Dan North，Evan Botcher和Graham Tackley也在这篇文章中对此作出了评论。

2012年5月，之前首次提及微服务的软件架构师小组最终决议，以“microservice”为最合适的架构名称。

2014年，Martin Fowler 和James Lewis 共同提出微服务的概念。在 Martin Fowler的博客中，他将微服务的定义概括如下：简而言之，微服务架构是将单个应用程序开发为一组小型服务的方法，每个应用程序运行在自己的进程中，并通过轻量级的通讯机制进行通信，通常是基于HTTP资源的API。这些服务是围绕业务功能构建的，并可以通过全自动部署机制独立部署。这些服务应该尽可能少的采用集中式管理，并根据所需，使用不同的编程语言和数据存储[6]。

相对于传统架构，微服务架构有一系列好处：技术异构更容易，新技术应用更自由，架构与组织架构相互促进相互优化，更好的建设和锻炼团队，扩展容易，部署简单（更新和回滚），高重用性，高弹性，替换陈旧组件更容易等等。

总而言之，微服务就是一些协同工作的小而自治的服务，它在技术决策上给了我们极大的自由度，使我们能够更快的响应日趋严峻的挑战和一些不可避免的问题。而且微服务有很多好处，它的很多架构思想也同样适用于各种分布式系统，相对于分布式系统或者面向服务的架构，微服务甚至更胜一筹，它可以把这些好处推向极致。

2. 本文研究内容

传统架构的发展及微服务架构的由来，微服务关键技术研究和实践，Kubernetes的架构和原理剖析，基于机器学习的应用程序在Kubernetes集群的部署编排，基于机器学习的密码强度评测微服务等。

3. 本文组织结构

第一章介绍了研究的背景和意义，具体讲述了传统架构的发展以及存在的问题和微服务架构的由来，并列举了比较有代表性的国内外的发展研究现状；第二章讲述了微服务架构设计的关键，主要从设计原则，容器技术，服务发现，通信机制，持续集成等几方面展开论述；第三章以谷歌Kubernetes为框架基础，以实际的组件进一步讲述了重要的微服务架构原理；第四章从原理分析，业务建模，一步步实现基于机器学习的密码强度评测服务；第五章针对第四章实现的服务，搭建相关环境并部署编排服务和进行相关验证；第六章对论文整体进行了概括和总结，并对微服务架构设计的未来进行了展望。

微服务架构设计的关键技术研究

1. 设计原则

1.1 单一职责

对于伴随着功能越来越多带来的代码库越来越大而导致的一系列问题最好的解决方式就是通过抽象层或者模块划分来保证代码的内聚性。单一职责原则对内聚性做了很好的阐述，正如Robert C. Martian在其专著《敏捷软件开发》中对单一职责的描述：把因为相同原因而变化的东西聚合到一起，而把因为不同原因而变化的东西分离开来[7]。

微服务通过业务的边界来划分独立服务的边界，应用这一理念，就可以很好地明确某个功能的代码在哪，而且微服务的功能专注于某些业务逻辑以及在某个边界之内，这样也同时避免了传统架构中因代码库过大而产生的一系列问题。当然对于服务多小才是小的也就是服务粒度划分问题，不同的人有不同的见解，团队架构、安全因素、技术难题、迭代速度等这些考量都可能成为服务划分的依据。我们需要注意的是，服务被划分的越小，独立性越明显的同时随之而来的管理越多的服务就会越复杂，所以不管什么方式都需要做到具体情况具体分析和适度。

1.2 自治性

每个微服务都是一个个的独立个体，可以独立部署在PAAS（Platform As A Service，平台即服务）上，也可以作为一个独立的进程存在。微服务之间均通过网络调用进行通信，这在加强服务间的隔离性的同时还降低了耦合。对于如何更好地解耦，也就是避免一旦出现问题，不至于波及部分服务甚至所有服务不可用，有一个黄金法则，也就是“是否能够修改一个服务并将对其部署，而不影响其它任何服务”。也就是需要我们通过正确的建模和合理的暴露API来让服务本身要做到充分的自治。

1.3 领域驱动设计

领域驱动设计主要专注于如何对现实世界的领域进行建模。世界著名软件建模专家Eric Evans在其专著《领域驱动设计——软件核心复杂性应对之道》中引入了新的概念限界上下文（Bounded context）：一个给定的领域都含有多个限界上下文，每个限界上下文中的模型分成两部分，一部分需要与外部通信，另一部分则不需要。每个限界上下文都有明确的接口，该接口决定了暴露哪些模型给其它的限界上下文[8]。

 领域逻辑告诉我们对于模块和服务的划分应该遵循共享特定的模型，而不是共享内部表示这个原则，这样就可以做到松耦合。而松耦合可以保证可以独立的修改及部署单个服务而不需要修改系统的其它部分，这是微服务设计中最重要的一点。除此之外通过共享模型和隐藏模型我们可以更加清楚的识别领域边界，更好地隐藏边界内部实现细节，而边界内部是高相关性的业务，以此做到了高内聚，这样可以避免对多处相关地方做修改和同时发布多个相关微服务而带来的不可控和风险，同时能更快速的交付。

2. 容器虚拟化技术

容器虚拟化技术是一种更底层的基础设施，甚至可能会颠覆以虚拟化技术为核心的IAAS（Infrastructure as a Service，即基础设施即服务）。容器像一个集装箱一样把软件封在一个盒子里，然后用传统的标准化方法把软件部署在服务器，而不需要关注软件本身的实现细节。容器技术是比DDD和微服务更加具体化的东西。

2.1 Docker发展简介

说到容器虚拟化技术，很快会联想到Docker，Docker作为一个开源应用容器引擎，最初是由dotCloud公司创始人Solomon Hykes在法国时发起的一个公司内部的项目，是基于dotCloud公司多年的云服务技术的以一次革新，在2013年以Apache2.0授权协议开源头，开始在Github上维护其主要代码[9][10]。Docker项目加入了Linux基金会，并成立推动开放容器联盟（OCI），经过近几年的快速发展已经成为了很多公司的标配，某种程度上也成为了容器虚拟化技术的代名词。

同传统虚拟化技术相比，Docker具有更高的性能和效率：1）更快速的交付和部署：开发者可以基于并引用各种标准镜像来构建自己特定功能的镜像，完成后镜像后，运维人员可以直接应用这个镜像进行部署；2）更轻松的迁移和扩展：Docker容器可以在包括物理机、虚拟机、公有云、私有云、混合云等各种平台上运行，跨平台支持能力非常强；3）更简单的管理和维护：基于Docker容器的镜像支持以增量的方式更新和分发，而且支持版本号操作，这些特性都为管理和维护提供了很大的便利[11]。