前言
身为一名积极好学的前端女朋友还是会经常问我,微服务那么多理念,你跟我讲完,我就忘了,可以再给我讲讲它的思想到底是啷个回事嘛~看在她这么刻苦奋进的情况下,加之我们公司也做了许多微服务的项目,对此还算有所研究,今天就深层次的讲讲微服务吧!
本文来源:博客园
本文作者:浅羽技术
原文链接:
https://www.cnblogs.com/qianyueric/p/14548566.html作者微信公众号:「 浅羽的IT小屋 」
单体架构
概念
单体架构也称之为单体系统或者是单体应用。就是一种把系统中所有的功能、模块耦合在一个应用中的架构方式。
特点
单体架构的特点主要有:
1. 打包成一个独立的单元(导成一个唯一的jar包或者是war包)
2. 以一个进程的方式来运行
单体架构
优点
易于开发: 开发方式简单,IDE 支持好,方便运行和调试。
易于测试: 所有功能运行在一个进程中,一旦进程启动,便可以进行系统测试。
易于部署: 只需要将打好的一个软件包发布到服务器即可。
易于水平伸缩: 只需要创建一个服务器节点,配置好运行时环境,再将软件包发布到新服务器节点即可运行程序(当然也需要采取分发策略保证请求能有效地分发到新节点)。
缺点
维护成本大: 当应用程序的功能越来越多、团队越来越大时,沟通成本、管理成本显著增加;当出现 bug 时,可能引起 bug 的原因组合越来越多,导致分析、定位和修复的成本增加;并且在对全局功能缺乏深度理解的情况下,容易在修复 bug 时引入新的 bug。
持续交付周期长: 构建和部署时间会随着功能的增多而增加,任何细微的修改都会触发部署流水线。
新人培养周期长: 新成员了解背景、熟悉业务和配置环境的时间越来越长。
技术选型成本高: 单块架构倾向于采用统一的技术平台或方案来解决所有问题,如果后续想引入新的技术或框架,成本和风险都很大。
可扩展性差: 随着功能的增加,垂直扩展的成本将会越来越大;而对于水平扩展而言,因为所有代码都运行在同一个进程,没办法做到针对应用程序的部分功能做独立的扩展
采用过时的单体架构的话,就会使得公司雇佣有潜力的开发者很困难,应用无法扩展,可靠性很低,那么我们再来看看微服务架构是怎样的呢?
微服务架构
概念
微服务是一种架构风格。一个大型的复杂软件应用,由一个或多个微服务组成。系统中的各个微服务可被独立部署,各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并且能够很好的完成该任务。
架构核心
核心部分
网关集群:数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等。
业务集群:一般情况下移动端访问和浏览器访问的网关需要隔离,防止业务耦合。
Local Cache:由于客户端访问业务可能需要调用多个服务聚合,所以本地缓存有效地降低了服务调用的频次,同时也提示了访问速度。本地缓存一般使用自动过期方式,业务场景中允许有一定的数据延时。
服务层:原子服务层,实现基础的增删改查功能,如果需要依赖其他服务需要在 Service 层主动调用。
Remote Cache:访问 DB 前置一层分布式缓存,减少 DB 交互次数,提升系统的TPS。
DAL:数据访问层,如果单表数据量过大则需要通过 DAL 层做数据的分库分表处理。
MQ:消息队列用来解耦服务之间的依赖,异步调用可以通过 MQ 的方式来执行。
数据库主从:服务化过程中必经的阶段,用来提升系统的 TPS
架构
常见的架构有:
1. 客户端与服务端的
2. 基于组件模型的架构(EJB)
3. 分层架构(MVC)
4. 面向服务架构(SOA)
特点
1. 系统是由多个服务构成
2. 每个服务可以单独独立部署
3. 每个服务之间是松耦合的。服务内部是高内聚的,外部是低耦合的。高内聚就是每个服务只关注完成一个功能。
优点
边界清晰:比如说一个电商平台,我们以前是部署在一台服务器上,所有的代码打成一个war包。现在,我们可以给它拆分开:用户服务,积分服务,支付服务,仓储服务,信息服务,地图服务等等,每一个微服务只关注一个特定的业务功能,这样的话开发和维护单个服务都比较简单,因为它的边界足够清晰,业务也足够清晰,用户服务,只做好用户的事情就好了,相较于之前的大而全的单体服而言,每个微服务的代码量也比较少。
效率高:单体服务随着代码量变得越来越多,比如说百万行级别的代码,仅仅编译一次应用可能就需要花费很久,但是现在,如果一个地方有问题,比如说支付模块有问题,只需要单独修改支付模块,修改完支付模块之后,单独测试支付功能,单独部署支付模块就可以了,而不会影响整体的部署速度。
技术栈不受限制:每一个服务可以使用不同的技术栈来实现,由于不同的服务之间是通过restful API来通信的,所以每个服务可以使用不同的技术框架,使用不同的存储库来实现;
拓展性更强:随着业务的发展,用户量变得越来越多,或者说订单量猛增,这时我们可以专门去优化这个订单服务,给这个订单服务提供更高配置的机器,而其他并没有遇到瓶颈的业务,比如说短信服务,我们可以暂时不用动。
缺