微服务架构与实践摘要

　　微服务架构与实践摘要

　　一、微服务架构图：

　 

　　二、技术介绍：

　　 

　　三、为什么选择微服务架构

　　首先，当然是该套架构方法有著名的成功经验才导致大家去了解与学习它。

　　微服务架构中的 “微” 体现了其核心要素，即服务的微型化，就是每个服务微小到只需专注做好一件事。这件事紧密围绕业务领域，形成高度内聚的自治性。

　　一些大型应用系统，采用模块化的分层式架构，所有的业务逻辑代码最终会打进一个代码库中统一部署。这种应用架构的问题是，全部开发人员会共享一个代码库，不同模块的边界模糊，实现高内聚、松耦合极其困难。如果你接手过这类应用的遗留系统，尝试去做重构改进时，肯定碰到过这类场景，改了一个地方好几个其他模块也需要同步改动，模块的边界轻易被穿透，这种应用的架构有一个很形象的名字叫 “洋葱架构”，洋葱的特点就是一层又一层的粘连，重构这样的系统就像切洋葱一样让人忍不住飙泪。

　　微服务架构强调 “微”，但之前有些采用了 SOA 服务化架构思想的系统会搞出很多胖服务来，一点也不微，这依然带来耦合。

　　这一点只能依赖系统架构师的服务化建模能力了，但微服务架构强调每个服务一个进程，使用进程为边界来隔离代码库至少让同一应用系统不同层次的开发人员享有自己完全自治的领地，每个微服务都有一个掌控者。从某种程度上让不小心做错事，例如：跨出服务边界的代码耦合依赖，变得没那么容易。

　　一个 20 人的团队维护一个 40 万行共享代码库的单一应用，在里面修改 bug 和添加功能都将十分困难。

　　有一篇文章 《程序员的成长和代码行数的关系》 里提到大部分普通程序员成长生涯的瓶颈在 2 万行代码左右，

　　超过这个代码行数的应用系统维护起来将倍感吃力，所以我们系统这两年的高速发展膨胀，已让团队维护起来倍感吃力了。

　　所以我们想要把一个大系统拆分成许多不同的微服务，每个微服务的规模大小控制在一个普通程序员的舒适维护区能力范围内。

　　微服务架构实施

　　把 1 个应用进程部署到 1 台主机，部署复杂度是 1 x 1 = 1，我们有 200 台主机，那么部署复杂度是 1 x 200 = 200。

　　把 1 个应用进程拆分成了 50 个微服务进程，则部署复杂度变成了 50 x 200 = 10000。

　　部署变得复杂和麻烦多了，同时监控的进程数也大幅增加，监控的复杂度也上升了很多。所以实施微服务架构是有很高成本的，只有系统的规模到了一定程度才适合，这也是为什么微服务架构实践诞生于大型互联网公司。

　　微服务推崇一切自动化的文化，这也是因为其运维复杂度的乘数级飙升，从开发之后的构建、测试、部署都需要一个高度自动化的环境来支撑才能有效降低边际成本。

　　《Building Microservices》一书对实施微服务架构有系统性的描述和很多业界案例的简单引用描述，这里不展开讲实施细节，那样就太长了。

　　我们这里简单总结下实施的要点：

　　自动化文化与环境：自动构建、自动测试、自动部署。

　　围绕业务能力建模服务，松耦合、高内聚、暴露接口而隐藏实现细节。

　　服务协作模型：中心化（乐队模型：中心指挥）和去中心化（舞蹈模型：群舞自组织），各自场景不同。

　　服务交互方式：RPC/REST/WS 技术很多但考虑统一。

　　服务部署的独立性、失败隔离性、可监控性。

　　服务流控：降级、限流

　　服务恢复：多考虑故障发生如何快速恢复而非如何避免发生故障。

　　服务发布：灰度。

　　服务部署：一服务一主机模型，需要虚拟化（Hypervisor）、容器化（LXC， Docker）等技术支持，实现硬件资源隔离。

　　服务配置：中心化配置服务支持

　　康威定律：任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。系统架构的设计符合组织沟通结构取得的收益最大。

　　伯斯塔尔法则：服务健壮性原则 —— 发送时要保守，接收时要开放。

　　自进化的微服务架构

　　早期人们把软件开发和建筑学作类比，Architect 这个词来就源于建筑学，但软件产品和建筑物的性质完全不同。建筑物本身一旦建成则几无变化了，唯有老化后被替代了。软件系统会在其生命周期中不断变化，唯一不变的就是变化，拥抱变化，需用进化的观点看待架构演进。与此类似的是城市，城市的演进发展总是渐进式的，我们不会在一座旧城旁建一座新城，然后把旧城的居民迁到新城然后再把旧城废弃了。但经常我们会用这样的方法重写一个新系统并替换掉旧系统，付出高昂的成本。

　　而微服务架构思路是不鼓励这种方式的，系统的演进是通过局部的新增、改进或替换微服务来实现的。而微服务本身的变化周期是不同步的，从整体上就形成了一种渐进式的、符合自然进化的系统演进道路。所以 Architect（架构师）更像是城市规划师而非建筑师，对软件系统进行类似城市划分区域的规划。

　　从常识上我们知道把学校和住宅放在一个区域内是合理的，但如果再放一个垃圾处理厂则不合理。学校和住宅就是提供两种不同能力的服务，垃圾处理厂是另一种服务，但现实中软件系统的规划其实不像城市规划那么有常识性，这是架构师能力和经验发挥作用的地方，前期规划的不合理会在后期带来维护成本的放大。

　　每个历史悠久的城市都有各自不同的味道，城市中的人、时间、技术进步共同决定了今天城市的面貌。微服务架构的妙处就在于它符合城市历史演进规律，随着人员变化、时间、技术改进而引发自然渐进式的进化。

　　微服务架构与架构师

　　架构师的一个角色是技术决策者，技术决策涉及很多权衡取舍（trade-off），而微服务架构给了架构师更多权衡取舍的空间。

　　每个微服务实现层面的技术决策更多由服务负责人决定，服务的分拆伴随着决策权和责任的分拆，这也减轻了整体应用负责人的责任负担。

　　架构师解放出来从整体和全局上将更加关注服务之间是如何交互，并确保能正确的监控系统全局的健康性。

　　分拆了服务实现的技术决策权，那何时又该适当的介入以避免服务实现不当危及整体系统的安全？

　　就像教孩子骑车，你无法代替它们去骑，你小心的看着他们骑的歪歪扭扭，担心他们摔倒。事实上，孩子骑车摔倒的次数比你担心的要少，但如果每次快摔倒时都去扶住，那么他们也许永远学不会骑车。当孩子骑车失控时冲向了繁忙的马路或要冲下路边的深沟，那时才有必要介入去稳住他们。

　　架构师工作在抽象和具体两个层面：

　　架构是一项技术工作，技术工作要服务于组织的战略目标。大量的工程实践在每日的工作中不断变化，而渐渐稳定的实践方式被抽象提炼为一系列原则。原则的普及带来整体效率的提升和边际成本的下降，以更有效的支持组织战略目标的快速达成。另外也要确保这些原则不是让开发人员的生活变得更凄惨而是更美好。跟踪新技术发展确保能在合适的时候做出正确的取舍折衷。让开发人员理解某项技术决策的影响和制约以便最有效的执行，甚至在特定情形下深入到代码的实现层面。

　　文章开头说了，这是我们实施系统的第四个大版本，而之前每一个大版本升级都是一次旧城倒新城的整体搬迁。而微服务架构天然的自然进化属性是否预示着这应该是最后一个大版本升级了？微服务架构述说着没有永恒的架构，只有进化的架构，但微服务架构不是银弹，也没有银弹。

　　1. 单块架构及其面临的挑战

　　1.1 三层架构

　　三层架构包括表示层、业务逻辑层、数据访问层。

　　1.2 单块架构

　　所有的功能在一个工程项目中。

　　单块架构常见的架

　　 

　　1.3 互联网产品特性

　　创新成本低、需求变化快、用户群里庞大。单块架构无法满足。

　　2.微服务架构综述

　　2.1 什么是微服务

　　微服务架构模型（Microservice Architect Pattern）

　　引用下当今世界软件开发领域最具影响力的五位大师之一的定义：

　　微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间 互相协调、互相配合 ，为用户提供最终价值。每个服务运行在其独立的进程中，服务于服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。 —摘自 马丁·福勒先生的博客

　　2.1.1 多微才够微

　　微服务架构通过对特定业务领域的分析与建模，将复杂的应用分解成为小而专一、耦合度低并且高度自治的一组服务。

　　代码行数和开发时间都不能衡量是否”微”的重要因素。

　　“微”所表达的是一种设计思想和指导方针，是团队或组织共同努力找到的一个平衡点。仁者见仁智者见智，但要遵循如下2点：

　　业务独立性： 保证微服务具有业务独立性的单元，如：

　　业务： 订单，产品，合同

　　功能：发送邮件，单点登录验证，数据库同步

　　团队自主性： 考虑团队的沟通及写作成本，一般建议不超过十人。

　　2.1.2 单一职责

　　高内聚：一个模块各个元素彼此结合的紧密度高。

　　低耦合：对于一个完整的系统，模块与模块之间，尽可能的独立存在。

　　SRP ：（Single Responsibility Principle，单一职责原则）：即一个对象应该只有一个发生变化的原因，如果一个对象可被多个原因改变，那么说明这个对象承担了多个职责。

　　### 2.1.2 轻量级通信

　　服务之间应通过轻量级的通信机制，实现彼此间的互通互联，互相协作。

　　格式： XML，JSON

　　协议： HTTP，REST（Representational State Transfer，表述性状态传递）

　　2.1.3 独立性

　　交付过程中，开发，测试以及部署的独立性。改变某个服务时，对其它服务不产生影响。

　　2.1.4 进程隔离

　　理论上，多个服务部署到一个节点上，并且能运行在不同的进程中，且互不影响，但是不推荐这么做。

　　因为增加了部署和扩展的复杂度，建议还是一个服务一个节点。

　　总结： 微服务架构就是将单一的应用程序划分为一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发，独立运行，独立测试以及独立部署。

　　2.2 微服务的诞生背景

　　互联网行业的快速发展，敏捷、精益方法论的深入人心，单块架构系统面临的挑战，容器虚拟化技术（Docker），

　　2.3 微服务和SOA

　　2.3.1 SOA（Service-Oriented Architecture，面向服务架构）

　　2.3.2 微服务和SOA

　　2.4 微服务的本质

　　1） 服务作为组件（组件能独立部署）;2）围绕业务组织团队;3）关注产品而非项目;4）技术多样性（支持各种开发语言）;5）业务数据独立（数据库也独立）;6）基础设置自动化;7）演进式架构

　　2.5 微服务不是银弹

　　独立性，单一职责，技术多样性

　　2.5.1 分布式系统的复杂度：性能，可靠性，异步，数据一致性，工具

　　2.5.2 运维成本 配置，部署，监控与告警，日志收集

　　2.5.3 部署自动化

　　2.5.4 DevOps 与组织架构

　　2.5.5 服务间的依赖测试

　　2.5.6 服务间的依赖管理

　　微服务架构将一个应用拆分成多个独立的、具有业务属性的服务，每个服务运行在不同的进程中，服务与服务之间通过轻量级的通信机制互相协作、互相配合，从而为终端用户提供业务价值。同时，每个服务可以根据业务逻辑，采用不同的语言、框架、工具以及存储技术来解决业务问题。因此，微服务架构强调的是一种独立开发、独立测试、独立部署、独立运行的高度自治的架构模式，也是一种更灵活、更开放、更松散的演进式架构。

　　3.构建第一个服务

　　3.1 场景分析；3.2任务拆分

　　1）Hello World API;2）代码测试与静态检查；3）构建Docker映像；4）部署Docker映像；5）持续集成与交付；6）监控与告警；7）日志聚合；8）功能迭代

　　4.Hello World API

　　Ruby；

　　Rack：Ruby的Web应用抽象接口；

　　Rack Gem： Rack辅助类的集合；

　　RSpec：代码测试工具

　　Rubocop：代码的静态检查

　　5.构建Docker映像

　　Docker：开源的Linux 应用容器（Linux Container）引擎。

　　Boot2docker：Mac下轻松搭建整个Docker

　　Docker Hub：

　　Docker 映像存储介质的比较

　 

　　6.部署Docker映像

　　AWS:Amazon Web Services

　　Amazon EC2： （Amazon Elastic Compute Cloud）

　　Infrastructure As Code：基础设施自动化

　　7.持续交付流水线

　　Snap-CI： 持续集成工具，ThoughtWorks

　　提交、验证、构建、发布。

　　Jenkins

　　8.日志聚合

　　Splunk：日志管理工具，日志聚合，日志搜索，语义提取，对结果进行分组、联合、拆分和格式化，强大的可视化功能，电子邮件提醒功能。

　　核心：数据（采集器）转发器、数据索引器、搜索、分析和可视化、

　　LogStash：收集日志、过滤日志、结果输出。

　　ELK： ElasticSearch、LogStash、Kibana

　　9.监控与告警

　　Zabbix、Ganglia、NewRelic、Nagios、OneAPM。

　　Nagios： Nagios Ain’t Goona Insist on Saintood，免费的开源IT基础设施监控系统。 能有效监控Windows、LInux、VMware和UNIX主机状态以及交换机、路由器等网络设置。同事，它能够实现错误通知、事件处理。一旦主机或服务状态出现异常，Nagios会发送邮件或短信第一时间通知IT运维人员，并在状态恢复正常后发出邮件或短信通知。

　　Nagios结构： Nagios核心、Nagios插件。

　　Nagios网站： http://www.nagios.org/

　　Nagios原理，Nagios安装，Nagios配置。

　　10.功能迭代

　　10.1定义模型；10.2持久化模型;10.3 定义表现形式，10.4实现API;10.5服务描述文件

　　11.微服务与持续交付

　　持续交付的核心：小、频、快。小批量价值流动，频繁可发布，快速反馈。

　　微服务架构与持续交付：

　　１） 开发

　　独立代码库、服务说明文件、代码所有权团队、有效的代码版本管理工具【git，Mercurial，svn】、代码静态检查工具【SonarQube，cane】、易于本地运行）；

　　２） 测试：

　　集成测试的二义性，mock和stub，接口测试，测试的有效性

　　3） 持续集成： Jenkins，Bamboo，在线持续集成平台：Travis-CI，Snap-CI.

　　4） 构建： Docker

　　5） 部署： A.部署环境：基于云平台（IAAS，PAAS），基于数据中心，基于容器技术（Docker）

　　B.部署方式：手动部署，脚本部署，基础设施部署自动化（Chef，Puppet，Ansible），应用部署自动化，映像部署，容器部署

　　6）运维： 监控，告警，日志聚合

　　Asgard： netflix asgard https://github.com/Netflix/asgard

　　12. 微服务与轻量级通信机制

　　12.1 同步通信与异步通信

　　1）同步通信与一步通信的选择 ;

　　2）远程调用RPC（Remote Procedure Call 远程过程调用） 远程过程的核心：客服端/服务端模式（客户端客户代理存根［Stub］，服务器代理存根［Skeleton］）;RMI（Remote Method Invocation 远程方法调用）

　　优点：耦合度高

　　缺点：灵活性差，依赖于变成语言以及特定平台，

　　二进制，客户/服务端提供序列化，反序列化操作，任何一方发生变化，另一方就要造成影响

　　3）REST（Representational State Transfer 表述性状态描述;Resource 资源［返回数据］，Representation 表达，State Transfer状态转移，Uniform Interface 统一接口 GET，POST，PUT，DELETE） 概述，软件架构风格，

　　优点 ：与语言无关，与平台无关，水平伸缩容易。

　　缺点 ：如何标准化资源结构：业务增长，逻辑增加后，服务器端对内容的响应结构会越来越复杂［响应结构：是指服务器段的响应内容结构，即资源结构］，++可能企业内部的不同部门，不同小组，对同一资源，所定义的结构不尽相同++.

　　如何处理资源的相关链接： 大多数返回JSON，JSON最大的遗憾就是没有对超链接处理做内置的支持。对于调用的客户端，++每次需要查看相关的接口文档，才能了解如何修改资源的状态++.

　　如：多个接口：获取用户接口，获取用户好友接口，用户文章接口。如果REST只有开放三个接口，但是用户好友和用户文章实际上是用户接口的子链接就可以的，但是JSON不支持。

　　REST的HTTP并不是低延时通信的最好选择 对低延时要求的场景，可以选择底层协议，如果UDP（User Datagram Protocol）或其它的RPC框架。

　　开发成本略高 传输格式为JSON或XML，则需要来解析文本格式协议，还好当前开源工具库成熟。

　　4）HAL（Hypertext Application Language） ： 轻量级超文本应用描述协议。HAL的实现基于REST，并有效的解决了REST中的资源结构标准化和如何有效定义资源链接的问题。

　　核心：状态（State），链接（Links），子资源（Embedded Resource）。

　　状态 资源本身固有的属性。

　　链接 定义了与当前资源相关的一组资源的链接的集合。包括链接名称、目标URI，访问URI的参数。

　　子资源 描述在当前资源的内容，其嵌套资源的定义。

　　HAL浏览器： （HAL Brower）

　　5）MQ ：核心部分，访问方式.RabbitMQ，ActiveMQ，ZeroMQ

　　核心部分 ： 持久性（内存，磁盘，数据库），排队标准（常见FIFO），安全策略，清理策略，处理通知

　　访问方式 拉模式，推模式

　　消息队列的优缺点： 优点： 服务间耦合，异步通信，消息的持久化以及恢复支持。

　　缺点： 实现复杂度的增加，平台或者协议依赖，维护成本高，

　　6）* 后台任务处理系统* Resque=>Sidekiq（ruby），Delayed_job

　　轻量级通信，维护成本低，SDK和API支持

　　 

　　13.微服务与测试

　　13.1微服务的结构

　　业务模型（Domain），业务逻辑（Service/Business Logic），模型存储（Respository），资源定义（Resource 包括表述内容，表述格式），网关集成（Gateway/Http Client）。

　　13.2微服务的测试策略

　　测试金字塔。 单元测试，接口（契约）测试，集成测试，组件测试，端到端测试，探索。

　　单元测试 （Unit Testing）被测单元依赖于模拟部分（MOCK，STUB），被测单元依赖于真实部分。

　　接口（契约）测试 Pact测试框架

　　集成测试 （Integration Testing），自顶向下集成（Top-Down Integration），自底向上集成（Bottom-Up Integration）。测试内容： 网关，模型存储。

　　集成测试弊端： 运行效率低，运行结果不稳定，反馈周期慢。

　　组件测试 （Component Testing），进程内测试，进程外测试。

　　端到端测试 （End-To-End Testing，System Testing）

　　14.使用微服务架构改造遗留系统

　　14.1 改造策略

　　最小修改（优先修改紧急，核心功能），功能剥离（构建接口，分离核心功能），数据解耦（数据库独立），数据同步（ETL Extract，Transform，Load），迭代替换（最小修改-》功能剥离-》数据解耦-》数据同步（-》独立服务）-》功能剥离）。

　　14.2快速开发实践

　　微服务快速开发模板（Microservice Template）：快速开发模板（Webmachine或Grape 作为Web框架，RESTful和JSON构建服务之间的通信方式，RSpec作为测试框架），代码生成工具，持续集成模板（Bamboo），一键部署工具（Asgard）。