一、传统架构的缺点
传统架构的典型代表就是单体架构,所谓单体架构就是所有应用是一个大家庭,应用的每个业务模块不分家。但是这种不分家、大杂烩方式的架构在应用业务越来越复杂的今天表现出一系列问题。
- 复杂性逐渐变高:大型网站一般有成百上千乃至上万个业务模块,模块边界不清,逻辑混乱,代码量大,难以理顺。
- 技术债务逐渐上升:技术人员水平不一,加之人员流动频繁,代码质量不易管理,交接工作也困难。
- 部署速度逐渐变慢:项目越来越庞大,启动速度越来越慢,启动时间占比高,效率低下
- 阻碍技术创新:旧项目技术老,市场人才少;牵一发而动全身,技术更新重构难度大,成本高,风险大。
- 无法按需伸缩:由于一体,不能根据某个业务模块的对服务器的某一领域单方面要求高而调整。如某个业务要求IO密集型,换为固态硬盘即可;另一个业务占用内存多,增加服务器内存即可。单体部署拓展性能要相互考虑各个模块,不能 因为一个模块的调整影响另一模块。
面对统架构的缺点,面向服务架构(SOA)便应运而生,而微服务架构是在SOA的基础上强调“业务要组件化和服务化”,可以说是对SOA的继承和发展。
二、微服务是什么
简而言之,微服务架构风格这种开发方法,是以开发一组小型服务的方式来开发一个独立的应用系统的。其中每个小型服务都运行在自己的进程中,并经常采用HTTP资源API这样轻量的机制来相互通信。这些服务围绕业务功能进行构建,并能通过全自动的部署机制来进行独立部署。这些微服务可以使用不同的语言来编写,并且可以使用不同的数据存储技术。对这些微服务我们仅做最低限度的集中管理
这是来自一段英文博客的翻译http://www.martinfowler.com/articles/microservices.html
三、微服务的特点
- 1. 每个微服务可独立运行在自己的进程里;
- 2. 一系列独立运行的微服务共同构建起了整个系统;
- 3. 每个服务为独立的业务开发,一个微服务一般完成某个特定的功能,比如:订单管理、用户管理等;
- 4. 微服务之间通过一些轻量的通信机制进行通信,例如通过REST API或者RPC的方式进行调用
四、微服务的设计原则
- 单一职责原则:每个微服务只需要实现自己的业务逻辑,其它的不必考虑
- 服务自治原则:每个微服务从开发、测试、运维、乃至数据存储都可以是独立的
- 轻量级通信原则:采用基于REST API http方式通信,不受语言、平台限制
- 接口明确原则:服务之间存在调用,设计之初就要明确各个服务的接口,尽量减少因设计不合理而改动
五、微服务的优点
- 易于开发和维护
- 启动较快
- 局部修改容易部署
- 技术栈不受限
- 按需伸缩
- DevOps
六、微服务的挑战
- 运维要求较高: 服务众多,服务间存在相互调用,出现问题不易定位,要求较高的运维水平
- 分布式的复杂性:要考虑服务的一致性、可用性、容错性等问题
- 接口调整成本高:由于服务间存在相互调用, 服务接口调整,被服务接口也得跟着变动
- 重复劳动:各个业务模块独立,都是一个微服务,某段相同的业务代码,不能抽离共用
七、微服务的代表框架
Dubbo:http://dubbo.apache.org/
Dubbo专注于服务治理,是由阿里开源,国内早起使用较为广泛,后贡献给Apache社区,主要阿里中间件技术团队在维护
SpringCloud:http://projects.spring.io/spring-cloud
SpringCloud提供了一整套的微服务解决方案,近几年在国内广泛流行开来,社区活跃度高,版本更新发布快,属于spring家族。
Dropwizard:http://www.dropwizard.io
Dropwizard由Yammer生产维护,目前已经更新到Dropwizard v1.3.8,在国内使用极其少。
参考:http://dockone.io/article/8539