微服务
使用各个子服务控制模块
的思想代替SOA中的总线。服务控制模块通常至少包含:服务注册与发布、路由、代理。
微服务与SOA的对比
- 目的:
- SOA强调异构服务之间的协作和契约,强调有效集成,最大化应用程序服务的可重用性;
- 微服务的目的是拆分解耦应用,专注去耦合,让不同不同的业务团队服务不同的微服务,专人专事,缩小迭代影响范围,让微服务更容易进行
水平扩展
;微服务遵循单一职责,是一种克服系统复杂性的分解技术。如果你觉得你的某个微服务很复杂,那么考虑看看是否拆分的不够细?也正是因为这种拆分,本质上增强了安全性和故障隔离;
- 部署方式:
- SOA服务不多,一般打包后直接通过war形式部署到服务器;
- 微服务由于数量众多,需要实现快速扩容和缩容,一般借助容器化技术来实现部署,微服务之间独立部署,互不影响;
- 服务粒度:
- SOA对粒度无要求,通常是粗粒度的,更强调的是接口的规范化;
- 微服务提倡进行细粒度的拆分,保证服务职责的单一。
SOA | 微服务 | |
---|---|---|
服务粒度 | 粒度较粗 | 细粒度拆分 |
部署难度 | 需要重新创建或者部署整个应用 | 每个微服务可以独立构建部署 |
通信开销 | 大部分业务模块在一个应用里面,通信开销低 | 更多的远程调用,增加了通信开销 |
存储 | 一般所有服务共享数据存储 | 每个可以拥有单独的存储 |
业务易上手 | 需要了解整个应用的业务,上手较难 | 单服务上手容易,但是服务集群理解比较难(复杂度守恒定律:业务复杂度不会因为迁移到了微服务而降低) |
通信方式 | SOA体系结构依赖于消息传递(AMQP,MSMQ)和SOAP作为主要的远程访问协议,协议偏重量级; | 使用轻量级协议,如HTTP/REST |
可扩展性 | 难以扩展 | 使用容器技术很方便扩展 |
1、微服务的优势
1.1、方便扩容与保证服务可伸缩性
正是因为微服务的拆解,让我们增加了系统的安全性和故障隔离,可以让我们针对不同的服务,实施不同的扩容和存储技术。
例如,一些微服务可能使用关系数据库,而另一些可能使用NoSQL数据库甚至挂载的文件系统。以这种方式构建应用程序增加了团队构建应用程序的可伸缩性。
1.2、降低耦合,利于团队协作与版本快速更新
在SOA系统,或者是传统的单体系统中,使用一个项目的时候,通常会有一个大团队的人在同一个项目的同一个分支上工作,并且总是互相干扰,出现各种代码冲突,随着代码增长,开发速度会呈现指数级增长。这是我们以前遇到过的问题,特别头疼,后来花了很大的精力对系统做了服务化改造拆分。
当然主导这个服务化改造也是需要申请不少资源的,即使没有新的业务上线。为了让老板认为我们正在做的改造是存在价值的,当时还写了改造前后的各种利弊对比。这是很重要的,我们总不能无故的去改造一个运行良好的系统。
有了微服务架构,应用程序由小型分散的开发团队构建,这些团队独立地工作和更改微服务。
1.3、服务自治
这使得测试和升级服务以及随时间增加功能变得更加容易。
最终,如果一个微服务在规模和功能上增长,它可以被分解并分成多个微服务,从而保持微服务的小型、可管理和自治。
1.4、让项目保持技术多样性
最后,采用微服务体系结构允许使用最适合其开发的任何语言
和技术堆栈
来编写单个服务。并没有严格的限制所有的微服务都必须使用相同的技术来开发,只要它们都通过相同的轻量级协议(如HTTP和消息)进行通信,并且数据结构以相同的格式进行序列化(JSON是最流行的选择)。
微服务的特点是:
- 轻量级的组件;
- 服务独立的部署能力;
- 轻量级、粗粒度api;
- 轻量级的服务总线;
- 轻量级的数据存储;
1.5、避免了单体系统开发效率低下的问题
单体系统要么是数据库变得太大了,要么是代码行太多了,更有可能的是,现在的开发人员不能快速地添加新特性。微服务体系结构避免了单体系统的缺陷,使用真实且可靠的分解技术来解决这些缺陷,并将重点放在敏捷开发和可替换性上,而不是可重用性上。
此外,与单体系统不同,微服务是一个可持续的体系结构,通过添加新的微服务来满足快速变化的业务需求,而不是修改(和破坏)旧的服务。
2、微服务面临的问题
没有什么架构是免费的
尽管微服务有很多好处,但它并不是万能的。微服务在减轻整体应用程序固有的许多问题的同时,也带来了其他挑战。与技术领域的任何事情一样,总是需要在不同的体系结构和微服务之间进行权衡。
2.1、增加了运维的复杂度,以及维护微服务集群的复杂度
它所提供的敏捷性和开发速度是以增加操作复杂性为代价的,因为自然有更多的活动部件(或服务)—可能比单体应用还要多。
使用微服务架构可能会增加运维开销。 使用这种方法,您的部署可能需要大量资源。您可能需要更多的时间和精力来创建基础架构。 所有服务可能都需要群集以实现故障转移和弹性。 您的系统可能具有数十个单独的组件,并且在您添加新功能时,它将变得越来越复杂。
您可能会得到一个由20或30个或更多服务组成的解决方案,而不是一个整体系统,每个服务都运行多个进程。
最佳实践是,您应该通过DevOps自动化解决这些额外的工作开销。
2.2、单体系统迁移到微服务比价困难
**把单体系统迁移到微服务也是一个巨大的工作量。**不推荐用微服务重写系统,这不太现实,特别是单体系统业务比较复杂的时候。建议采用一种更渐进的方法,逐步地重构一个单体系统,逐渐地将它转变成一个由微服务组成的“新”应用程序。随着时间的推移,单体应用程序实现的功能数量会减少,直到完全消失或变成另一个微服务应用程序。最后,不要觉得有必要立即开始分解一切;花时间和工作在最合理的方式为你的团队。
2.3、提高了开发的技术门槛
在开始实际的迁移过程之前,我们得思考权衡以下问题:可以肯定的是,具有微服务体系结构的系统提供了大量的好处,例如独立部署、强大的子系统边界和技术多样性。
但是,因为微服务是一个分布式系统,它带来了开发分布式应用程序相关的复杂性的代价,如:独立的数据模型、微服务之间的弹性通信、最终一致性和操作复杂性等。开发和运行大规模的分布式服务也不是一件容易的事情。
在实际的把单体系统拆分为微服务的过程中,**不建议用服务大小来衡量拆分效果,而是拆分的业务边界,可以考虑使用DDD的方式去进行建模设计。**DDD是我们架构师工具箱中用于标识和设计微服务的优秀工具。
3、微服务技术体系
微服务需要关注的点很多,下面画了一张图来表述:
总的来说,微服务MSA架构需要以下技术点的支持:
- 配置管理;
- 服务发现和负载均衡;
- 弹性和容错;
- API管理;
- 服务安全;
- 日志管理;
- Metrics监控;
- 分布式调用链追踪;
- 调度和发布;
- 自动伸缩和自愈;
除了技术相关的,组织结构和团队文化也是很重要的。
下面是一般微服务涉及到的各种组件: