前言
微服务真的很火,很新,很潮,很多人说到微服务都能侃侃而谈,各种新鲜的名词、概念、框架止不住地蹦出来,但是:什么时候应当实行微服务呢?实行微服务应当要注意些什么呢?,首先我们了解下新生的微服务架构与传统架构有哪些区别。
传统架构
单体架构
Web应用发展早期,大部分Web工程将所有的功能模块打包到一起后放到Web容器中运行,很多企业的Jave应用程序打包成war,ear 它们的主要特点:
- 一个程序包包含了应用所有功能, 通常称之为单体应用。
- 架构单体应用的架构风格, 我们称之为单体架构, 这是一种比较传统的架构风格。
单体架构缺点
- 复杂性逐渐变高 - 由于业务的不断修改深入,系统变得越来越庞大,复杂度越来越高。
- 技术债务逐渐上升 - 参与项目的人员流动,水平不同,人员往往会埋坑,问题没有得到解决,坑越来越多。
- 部署速度逐渐变慢 - 业务模块增多,代码量不断增多,部署启动速度相应的越来越慢。
- 阻碍技术创新 - 技术在发展,历史的架构选型注定了系统形态,新的模块需求依然需要使用老旧的技术。
- 无法按需伸缩(出现IO或CPU瓶颈时需要兼顾或妥协)
微服务架构
微服务是什么
lMartin Fowler:简而言之,微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理。
来自:http://www.martinfowler.com/articles/microservices.html
微服务解决了什么
微服务特性
- 每个微服务可独立运行在自己的进程里;
- 一系列独立运行的微服务共同构建起了整个系统;
- 每个服务为独立的业务开发,一个微服务一般完成某个特定的功能,比如:订单管理、用户管理等;
- 微服务之间通过一些轻量的通信机制进行通信,例如通过REST API或者RPC的方式进行调用。
微服务的优点
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
- DevOps
微服务带来的挑战
- 边界清晰 - 软件架构开发中如何合理的划分边界,边界清晰和技术限制之间做出权衡
- 运维要求较高 - 服务之间相互依赖运维需要清晰的知道服务之间的依赖关系
- 分布式的复杂性 - 分布式系统固有的复杂性,网络问题,完整的监控,如何保持一致性,事务保障,高可用性等等
- 接口调整成本高 - 一个服务接口的调整可能涉及到多服务需要同时调整
- 重复劳动 - 一个个微服务既然名曰”服务”,就得五脏俱全,就得螺蛳壳里做道场, 麻雀虽小五脏全该有的基础功能数据库的访问,工具类使用,IO处理,网络,各个服务里面都得处理。
微服务设计原则
- 单一职责原则-[Single Responsible Principle] ,即每个服务只做一件事,并把这件事做好;
- 服务自治原则- 每个微服务需要有自己独立的开发、测试、部署、运维。
- 轻量级通信原则 - 通讯协议需要跨平台,跨语言,不要绑定技术栈。
- 接口明确原则 - 一个微服务接口的修改可能相关联的微服务也需要跟着修改,这时需要提前规划好,避免接口修改
总论
总的来说,从传统架构到SOA再到微服务架构,微服务带来了很多全新的东西,可以解决传统架构的一些问题,但同时对系统的架构技术也提出的更高的要求,实现微服务也需要一定的前提条件,,我们不能一味的认为微服务架构好。微服务这种分开当家当然潇洒,但要知道自己当家也有自己的累。