微服务架构概念索引 原

微服务从2013年（或许更早）开始就越来越热，从BAT之类的巨头到小小的只有几个人的技术公司，无不在谈论微服务。实际上微服务的概念早在半个世纪之前在理论层面就出现了。关于微服务理论介绍的文章太多，口才优秀的人可以分成上中下九章给你说上一天。本位用于总结微服务知识结构，略做引导。

云源生（Cloud Native）

现在但凡和软件技术有点裙带关系的机构、组织、人士都在谈论各种“云”。还有不少公司以云××、××云、×云×作为公司的名称。与IT技术沾一点边或者完全不沾边的各路人马都可以随时抛出“云应用”、“云计算”、“云数据”等听起来就很高大上的术语持续忽悠着你。

对于云技术（微服务）而言，2013年是一个分水岭，在这之前有一些零散的分布式应用的意识，但是没有一个系统性的概括。然后在2013年Matt Stine的Cloud Native概念横空出世。Cloud Native是一系列概念的集合，围绕这一系列标准可以构建从技术架构、到运维管理、再到团队协作的整体性框架。他让基于微服务的应用搭建成为一个标准流程，主要涵盖以下几点内容。

1. 微服务（分布式系统）。
   • 首先，微服务本身就是一个很具体的概念，简单的说就是：根据性能要求横向拆分为相同功能的负载均衡节点，根据业务要求纵向拆分为不同功能的服务节点。
   • 其次，微服务这个术语下还涵盖了大量概念，也是一个概念的集合，比如：熔断、降级、心跳检查、消息队列、负载均衡、服务注册、服务发现、去中心化、服务通信（RPC、RMI、TCP/IP)、分布式事物（分布式数据库）、分布式存储、分布式同步对象（数据）、缓存穿透、缓存雪崩、业务追踪、统一日志管理、API网关等等。每一个概念背后都是一项功能标准，都有一项或多项技术在支撑。通常优秀的微服务框架都会实现以上部分功能，同时支撑内部或外部扩展。比如要防止缓存穿透可以自己写一个Bloom Filter（布隆过滤器），或者缓存用Redis（>4.0)并添加过滤器插件，再或者在物理缓存之前再使用Redisson、Hazelcast之类的内存级缓存。
   • 最后，微服务也特指云服务分布式系统的底层技术。比如Dubbo、Spring Cloud、以及后面要提到的Service Mesh等，都会把他们称为微服务框架。

   虽然微服务这个术语自身已经有了足够丰富的内容，但是他仅仅是“云”技术的一个环节。

2. 康威定律。 在使用微服务框架的时候，不知道各位有没有想过这些问题：为什么微服务技术或团队是现在的结构？为什么微服务开发需要和敏捷模型（迭代模型）配合？为什么使用微服务的公司能够容忍团队之间使用不同的语言？ 以上这些问题早在半个世纪之前就给出了答案——康威定律。康威定律是微服务技术团队的基础理论，他主要由四个定律组成：
   1. 组织的沟通方式通过系统的设计结构来约束：沟通成本呈现指数增长（人于人之间的连线），必须把业务/小团队边界压缩在固定人员中（5~15人）。
   2. 无法完美但能高效。Bug永远有，与其追求无Bug的完美系统，不如追求可允许的修复速度。通过反复验证强化系统。这是敏捷开发、持续集成发布、自动化监控的本源——即使测试覆盖到100%也没法避免不出现bug，但是能在波及面可控的范围内快速解决问题。
   3. 线性团队同质化，业务团队内聚化。看下面2个图就明白（图片来源于网络，如有侵权请联系立即删除）。 1）

   

   2）

   

   图1）是一个线性团队，前端、后端、数据库分工明确层次清晰，然后开发出来的系统也会呈现出对应的样子，因为团队划分的结构决定了系统的最终形态。 图2）是一个以业务划分的团队，每一个团队都有一个完整的从前端到后端的“生态”。然后开发出来的系统就会各成一派别。 第三定律告诉我们小团队内部的沟通往往密集而且更加高效，按照这个方式划分的每个子系统自然会逐渐内聚，而团队之间更加倾向以接口沟通耦合性更低。仔细观察，现在包括BAT在内的互联网公司都是图2的团队结构。

   1. 系统的拆解倾向性。在架构演进的过程中，随着系统规模的增加合理的解决方法都是将复杂的问题拆分。比如数据库并发太高无法承担了，我们一般会执行以下几个步骤：
      1. 增加Redis之类的缓存工具，将原本是物理数据库的一个问题拆解成2个子问题，并分别去解决对应的更多问题。
      2. 横向按字段拆表，将一些频繁更新的字段独立到独立的表去以关联的形式存在。
      3. 纵向按照数据业务特征（例如时间）分区数据。
3. 敏捷开发与敏捷基础设施：在康威定律中已经解释了敏捷开发（迭代开发）对于微服务架构的重要性。说白了敏捷开发就是一种流程规范外加一些适合与流程规范的工具，比如GitLab、Jira之类的工具等被称为敏捷基础设施，敏捷工具和方法众多，比如每日站会、卡片式任务等等，这需要根据团队的需要和结构因地适宜。
4. DevOps：DevOps（Development、Operations）实际上并没有指定具体的技术实现，他就是一个从软件开发到产品上线发布的流程规范，只不过这个流程现在有大量的工具为我们提供支持。流程包括：
   1. 需求管理。
   2. 编码开发，单元测试（Junit、Jest白盒测试）。
   3. QA（黑盒测试）。自动化测试（Server walker）、代码质量监控（Sonar、EsLint）、接口测试（Jmeter、Loadrunner）。
   4. 上线发布运维。包括压力测试、多节点的运维管理、以及Cloud Foundry, Kubernetes, Apache YARN, and Apache Mesos等云平台的使用。

   这其中每一个过程都可以写成一本书。本人比较推崇CMMI的敏捷模型配合各种工具来使用。

5. CI（Continuous Integration）/CD（Continuous Deployment）：实际上CI/CD应该属于DevOps的范畴，他的关注点在程序员代码交付和缺陷测试之上。我们知道在任何时候，技术开发人员和测试人员都应该是密切配合的，一个迭代周期之内应该是开发先推动来测试，然后测试驱动开发。并不用把这个过程想象得太复杂，实际上可以用Jenkins相关的各种插件实现代码持续集成、自动化检测、测试环境持续发布上线。
6. 更多内容：除了以上几点，Cloud Native还涵盖了对一些细节的描述，比如分布式事物（最终一致性、容错性、可用性、缓存与实体同步）、弹性伸缩等。

相关文章和博客：

1. 微服务学习阅读清单：这是本节开始提到的Matt Stine个人博客提供的阅读学习清单，对于了解云技术非常有价值。附带说下，在Matt Stine2013年提出Cloud Native时还是Pivotal的Cloud Foundry负责人之一，现在已经是Pivotal的CTO了。有空也可以看看他的各种推文。附带推荐这篇文章——关于Cloud Native架构与Matt Stine的一次对话。
2. 微服务架构的理论基础-康威定律：这篇文章对康威定律的介绍非常透彻，也有许多自己的解读。值得一读。

Micro Service与Service Mesh

到目前为止微服务这个概念或者相关技术已经发展了许多年，相关的问题不断的被发现和解决，理论也在不断的完善。现在最火热的技术当属Service Mesh，在很多人看来它代表了微服务的最近技术潮流，或被称为第二代微服务技术。目前Service Mesh具有代表性的开源项目主要是：

1. Linkerd。
2. Envoy。
3. Istio。
4. Conduit。
5. NginMesh。
6. Kong。

上面这些项目，最火热的当属Istio了，含着金钥匙出生自大厂（Google、IBM）。上面的技术框架中前两者被称呼为第一代Service Mesh，后面的被称为第二代。据说国内唯品会公司的技术团队长期致力于Service Mesh的使用，不过没看到什么开源的项目出现。

一句话总结Service Mesh与之前微服务技术的差异：非侵入、分层设计、伴随模式（SideCar）。

关于Micro Service与Service Mesh的几篇优秀的博文：

1. 微服务和服务网格架构概念整理这是百度搜索的排名第一，内容优秀。
2. 唯品会的Service Mesh三年进化史我最早接触到Service Mesh的概念是源于和一名前唯品会架构师的合作，后来搜到了这篇文章。本文优点在于他在介绍演进过程的同时还将很多实现基本功能的开源技术都罗列了出来，对新上项目做技术选型有不错的参考价值。
3. 蚂蚁金服的 Service Mesh 演进之道这篇文章介绍了Service Mesh在金融级别的解决方案，细节介绍比较透彻。同时还讲解了一些从传统架构迁移到Service Mesh的经验。

从后面的这2篇文章可以看到，国内的大公司虽然起初都有使用开源Service Mesh框架的意愿，但是都走上的自研的道路。目前的各路Service Mesh架构远没达到Spring Cloud这种开箱即用层度，用来之后要花许多时间去解决各种坑，小规模团队慎用。

Boiler Plate Patterns与Boilerplate

Boiler Plate Patterns这个词来源于Spring官网关于Spring Cloud的介绍，直译为“锅炉样板模式”。首次见到时略微迷惑，曾一度怀疑自己之前对设计模式的理解是不是有什么偏差。经过一番了解之后有了大致的心得，在此记录总结。

原文在Spring Cloud的开篇位置：“Coordination of distributed systems leads to boiler plate patterns, and using Spring Cloud developers can quickly stand up services and applications that implement those patterns.”按字面意思直译为：一个平衡和谐的分布式系统会导致“锅炉样板模式”，使用Spring Cloud能够让开发者通过这个模式快速的搭建服务和应用。Boiler Plate Patterns这个术语概括总结Spring Cloud的基本使用模式，所以弄明白它背后的安逸对于使用Spring Cloud非常重要。

很多后端开发的码友应该知道中样板式代码的问题，它的英文原文就是Boilerplate Code，在很多业务系统长期维护的系统中，经过几代人的“耕耘”样板式代码的问题尤为明显。此外在前端开发中， Boilerplate是一个著名的开源HTML模板，也指代那些以及制作好，只要修改文字内容的网站模板。所以Boiler Plate Patterns可以理解为Spring Cloud为每一个微服务节点提供一种开发样板，业务开发人员按照样板结构去开发即可。一个优秀的架构师在做技术选型或编写底层框架时，时时刻刻都会考虑面向业务的开发人员会以何种方式去使用框架，有统一的样板或者模式来遵循是对于任何刚使用框架的开发者都是非常有价值的。

Memory Footprint、TPS、QPS

评估微服务框架优劣的主要有三个指标，分别是Memory Footprint、TPS、QPS。Memory Footprint是指内存占用情况，按照蚂蚁金服那一篇Service Mesh文章的介绍，一个与应用伴随的微服务节点占用内存应该控制在20M以下。按照Java的Jvm机制内存的占用并不太好评估，但是非大文件处理的应用控制在50M以内。 TPS（Transactions Per Second，事物处理/秒）和QPS（Queries Per Second，查询处理/秒）一般用于衡量吞吐量，通常大规模应用的TPS会要求过万。

这也是Golang在高并发分布式的新环境下发展出来的优势，很多Golang节点的TPS能到十万级别，而内存占用能控制在20M以内。

(adsbygoogle = window.adsbygoogle || []).push({});