微服务从2013年(或许更早)开始就越来越热,从BAT之类的巨头到小小的只有几个人的技术公司,无不在谈论微服务。实际上微服务的概念早在半个世纪之前在理论层面就出现了。关于微服务理论介绍的文章太多,口才优秀的人可以分成上中下九章给你说上一天。本位用于总结微服务知识结构,略做引导。
现在但凡和软件技术有点裙带关系的机构、组织、人士都在谈论各种“云”。还有不少公司以云××、××云、×云×作为公司的名称。与IT技术沾一点边或者完全不沾边的各路人马都可以随时抛出“云应用”、“云计算”、“云数据”等听起来就很高大上的术语持续忽悠着你。
对于云技术(微服务)而言,2013年是一个分水岭,在这之前有一些零散的分布式应用的意识,但是没有一个系统性的概括。然后在2013年Matt Stine的Cloud Native概念横空出世。Cloud Native是一系列概念的集合,围绕这一系列标准可以构建从技术架构、到运维管理、再到团队协作的整体性框架。他让基于微服务的应用搭建成为一个标准流程,主要涵盖以下几点内容。
虽然微服务这个术语自身已经有了足够丰富的内容,但是他仅仅是“云”技术的一个环节。
2)
图1)是一个线性团队,前端、后端、数据库分工明确层次清晰,然后开发出来的系统也会呈现出对应的样子,因为团队划分的结构决定了系统的最终形态。 图2)是一个以业务划分的团队,每一个团队都有一个完整的从前端到后端的“生态”。然后开发出来的系统就会各成一派别。 第三定律告诉我们小团队内部的沟通往往密集而且更加高效,按照这个方式划分的每个子系统自然会逐渐内聚,而团队之间更加倾向以接口沟通耦合性更低。仔细观察,现在包括BAT在内的互联网公司都是图2的团队结构。
这其中每一个过程都可以写成一本书。本人比较推崇CMMI的敏捷模型配合各种工具来使用。
相关文章和博客:
到目前为止微服务这个概念或者相关技术已经发展了许多年,相关的问题不断的被发现和解决,理论也在不断的完善。现在最火热的技术当属Service Mesh,在很多人看来它代表了微服务的最近技术潮流,或被称为第二代微服务技术。目前Service Mesh具有代表性的开源项目主要是:
上面这些项目,最火热的当属Istio了,含着金钥匙出生自大厂(Google、IBM)。上面的技术框架中前两者被称呼为第一代Service Mesh,后面的被称为第二代。据说国内唯品会公司的技术团队长期致力于Service Mesh的使用,不过没看到什么开源的项目出现。
一句话总结Service Mesh与之前微服务技术的差异:非侵入、分层设计、伴随模式(SideCar)。
关于Micro Service与Service Mesh的几篇优秀的博文:
从后面的这2篇文章可以看到,国内的大公司虽然起初都有使用开源Service Mesh框架的意愿,但是都走上的自研的道路。目前的各路Service Mesh架构远没达到Spring Cloud这种开箱即用层度,用来之后要花许多时间去解决各种坑,小规模团队慎用。
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是指内存占用情况,按照蚂蚁金服那一篇Service Mesh文章的介绍,一个与应用伴随的微服务节点占用内存应该控制在20M以下。按照Java的Jvm机制内存的占用并不太好评估,但是非大文件处理的应用控制在50M以内。 TPS(Transactions Per Second,事物处理/秒)和QPS(Queries Per Second,查询处理/秒)一般用于衡量吞吐量,通常大规模应用的TPS会要求过万。
这也是Golang在高并发分布式的新环境下发展出来的优势,很多Golang节点的TPS能到十万级别,而内存占用能控制在20M以内。
(adsbygoogle = window.adsbygoogle || []).push({});