微服务和传统服务架构

单块架构应用:功能集中,代码和数据中心化,一个发布包部署后运行在同一个进程中的应用程序

单块架构的优势:

1)易于开发

2)易于测试

3)易于部署

4)易于水平伸缩(所有的功能都会打成一个包,在集群中新建一个节点,配置好节点的运行环境,复制软件包到响应的位置,保证负载均衡的分发策略有效分发到当前节点即可)

面临的挑战:

1)维护成本增加,代码量过大,不利于快速定位问题

2)持续交付周期长:构建 部署和测试的实际都会随着代码量的增加而成倍的增长

3)新人培养周期长:业务熟悉和环境部署都会有很大的难度

4)技术选型成本高:较大规模的系统,最初的选型会影响新技术的使用

5)可扩展性差:

a 垂直扩展:增加服务器

b 水平扩展:在集群中添加节点,使用负载均衡(若应用有一部分是需要内存密集型缓存大量数据,有一部分是需要CPU密集型,需要进行大量运算,那么每次扩展新的节点都需要足够的内存和CPU来满足需求)

6)构建全功能团队难:会出现功能的扩展需要跨团队沟通

微服务架构:

是一种架构模式,提倡将单一应用程序划分为一组小的服务,服务之间相互协调,相互配合,为用户提供最终价值,每个服务运行在独立的进程中,服务间采用轻量级的通信机制相互沟通(通常是基于http的restful api),每个服务围绕自己的具体业务构建,可以独立部署,应尽量避免统一的,集中式的服务管理机制,对于具体的一个服务而言,应根据业务上下文,选择合适的语言 工具来进行构建,也就是:

通过对特定业务领域的分析和建模,将复杂的应用分解成小而专一的,耦合度低并且高度自治的一组服务,每一个服务都是一个小的应用

编译语言有良好的语言类型约束和编译期检查,但代码比较复杂

动态语言灵活性高,运行时可以改变其内存结构,无类型检查,无需写交较多类型相关的代码,但不方便调试

开发 测试 部署完全独立,语言独立

服务与服务之间相互独立,相互隔离

在单块架构中,应用程序的代码虽然被分成逻辑上的3层或者4层,但并非物理上的分层,所有的功能经过编译,打包,部署后还是会运行在同一个进程中,这就意味着对应用部署时必须停掉正在运行的服务,部署完成后再重新启动进程,无法独立部署

一般为了代码的重用性,会把重复的代码封装成组件(可独立升级,独立替换掉的部分),传统架构中,通常是共享库,比如jar包或者是win下的dll等

但在微服务架构中,应用程序由多个服务组成,每个服务都是一个具有高度自治的独立业务实体,每个服务可以运行在一个独立的进程中,不同的服务可以轻易的部署到不同的主机上

理论上可以把不同的服务部署到同一个节点上,运行到不同的进程里,但是不推荐,既然是微服务,最好保证高度的自治性和隔离性,运行在同一个节点上,虽然省去了节点的开销,却增加了部署和扩展的复杂度,部署某一个新的服务时,可能会对该节点的原有服务造成影响,另外随着业务的发展,可能某些业务需要水平扩容,有些不需要,如果不能有效的组织服务,可能会给服务的水平扩容带来不必要的麻烦

docker:

1)可以更快的交付和部署,开发者可以使用一个标准镜像来构建镜像,开发完成之后,运维人员可以直接使用这个镜像来部署

2)可以更轻松的迁移和扩展,包括物理机,虚拟机和公有云,私有云等,这种兼容性可以很方便的将应用程序从一个平台直接迁移到另一个

3)更简单的管理,使用docker,所有镜像的修改都可以用增量的方式发布和更新,从而实现自动化和高效的管理

可以有效的解决微服务架构下,服务粒度细,服务数量多导致的开发环境搭建,部署以及运维成本高等的问题

微服务的本质通常包括:

1)服务作为组件

2)围绕业务组织团队

3)关注产品而非项目

4)技术多样性

5)业务数据独立

6)基础设施自动化

7)演进式架构

对应解释:

1)服务作为组件

在传统领域,我们通常把公用的部分抽离出来,构建出共享库,从而达到解耦和复用,但,共享库是平台和语言相关的,并且要和应用程序运行在统一进程中,也就是共享库的更新,意味着整个应用要被更新,需要重新部署,如果有多个共享库组件组成,任何库的变更都将导致应用需要重新部署

微服务也可以认为是一种组件,运行在不同的进程中,每个服务的变更仅需要重新部署自身服务即可,可以跨平台,跨语言

当然,微服务也有它的不足之处,就是分布式调用比进程内通信需要消耗更多的时间,并且严重依赖网络的稳定性和可靠性

2)围绕业务组织团队

传统架构里,我们通常会按照技能去划分团队,懂服务器的运维人员,用户体验设计师,DBA,后端开发人员,当团队按照这个维度去划分后,某些简单的需求变更,可能都会出现跨组织跨团队的协作,沟通的成本高

微服务是主张以业务为核心来组织团队,团队中的成员具有多种多样的技能

3)关注产品而非项目

项目模式就是项目启动后企业或者组织会从不同的技能资源池中抽调不同的资源,组成团队并完成项目,项目完成,团队解散,这种模式的弊端在于团队成员缺乏主人翁意识,难以制定有效的奖惩机制,团队成员也缺乏成就感

4)技术多样性

在微服务架构中,由于彼此相互独立,可以针对不同的业务特征进行不同的业务选型,有针对性的解决业务问题,比如要求快速开发的模块可以使用php python等,对性能有较高要求的模块可以使用C C++等,对于单块架构,切换语言或者框架,难度就会比较大,若没有完整的功能测试集,就很难平滑替换,且系统规模越大,风险越高

而对于微服务架构,我们可以挑选风险较小的访问作为尝试,快速得到反馈后再判断是否适用于其它服务,这样一项新技术的尝试失败并不会影响到整个产品的发展

5)业务数据独立

在微服务中可以使用不同的数据库类型来管理不同的数据,比如

在一个复杂的CRM系统中,产品数据种类繁多,更新也比较频繁,可以使用monogo这类文档数据库,它可以灵活地根据需求动态的调整

对于用户访系统时产生的临时会话信息,可以使用redis等键值系统进行存储

报表数据的结构变化不大,而且要求数据一致性,可以使用传统的mysql数据库

在采用微服务架构后原先一次就能部署完成的,现在可能需要每个部分单独部署,每个服务都需要部署带来的健康监控,错误回滚,日志分析等成本会明显增加,自动化部署的要求也就越来越高,可以使用云 devOps docker

单一的大而全的平台已经没办法满足我们的需求,单一的技术平台已经无法适应市场的快速变化,组织应该随着业务的发展不断去尝试新的架构设计,真正去做到业务驱动架构,架构服务于业务

微服务的优势:

1)独立性 2)单一职责 3)技术多样性

部署需要注意的问题:

1)分布式系统的复杂度 2)运维成本 3)部署自动化 4)devOps与组织架构 5)服务间依赖测试 6)服务间依赖管理

分布式系统的复杂性:

1)性能 由于是跨进程跨网络的调用,因此必须要考虑网络延迟以及带宽带来的影响

尤其是多个服务相互协作时,响应时间及性能对系统的影响

2)可靠性 由于网络,带宽,节点等自身可靠性因素的影响,任何一次组件间的远程调用,都可能失败,且微服务数量很多时,潜在更多的单点故障,所以 保证系统的可靠性,降低由于网络,组件引起的单点故障率,也成了构建系统的挑战

3)异步 由于夸网络调用,需要考虑异步的通信机制,这样出现问题时的调试就会变得很麻烦

4)数据一致性 为了保证数据一致性,我们通常考虑分布式事务管理,但是它会涉及到跨多个节点来保证数据的瞬时一致性,比起传统的事务成本就会高很多,通常,也会用最终的数据一致性来解决数据瞬时一致带来的系统不可用

5)工具 IDE工具,并没有为分布式调用提供良好的支持

有效的构建组动画部署流水线,降低部署成本,提高部署频率,是微服务架构的下一个跳战,传统的系统被拆分成多个相互协作的独立服务后,随着微服务个数的增多,如何清晰有效的展示服务之间的依赖关系,逐渐成为挑战

微服务强调的就是一种独立开发 独立测试 独立部署 独立运行的高度自治的架构模式,也是一种更灵活更开放和更松散的演进式架构

任务拆分:

1)同一时间聚焦一个任务

2)能够对每次完成的部分做持续集成

3)整体的进度容易追踪

原文发布于微信公众号 - JAVA高级架构(gaojijiagou)

原文发表时间:2018-03-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏IT大咖说

华为多年实践:ServiceComb在Service Mesh的探索与思考

内容来源:2018 年 6 月 27 日,华为微服务架构师田晓亮在“LC3微服务Workshop | 深入解读ServiceComb”进行《ServiceCom...

4044
来自专栏杨建荣的学习笔记

MySQL里的一些分布式方案

首先数据库是一个软件,最基础的功能就是数据存储和数据查询。对于数据的处理方式如果通泛来说是分为读和写,所以分布式方案的很多场景其实也是围绕着这两个维度来做的。

1541
来自专栏YoungGy

MMD_1b_PageRank

Graph data web graph history challenges and thumb flow formulation idea model si...

2317
来自专栏CSDN技术头条

微服务的鉴定与思考

微服务有且仅有一种非常专项的功能,通过远程API来提供系统其余功能。举个例子:试想一下仓库的管理系统,这样的系统中微服务可能提供的一些功能有: 接收库存 计算新...

2276
来自专栏云计算D1net

云备份选项保护公共云存储数据

如今,公共云供应商正在开发尖端产品,以使基于云计算的备份产品更有效地备份公共云的存储数据。 数据是当今大多数企业的命脉。而备份数据可能是IT行业人士最不喜欢做的...

3576
来自专栏华章科技

即将放弃Python 2.7的不止有Numpy,还有pandas和这些工具

最近,Numpy 团队的一份声明引发了数据科学社区的关注:这一科学计算库即将放弃对 Python 2.7 的支持,全面转向 Python 3。由于目前存在很多基...

931
来自专栏斑斓

系统架构 | 软件架构的一致性

在Brooks的力作《设计原本(The Design of Design)》一书中,提及“一致性”对软件的重要性。他认为:“一致性应该是所有质量原则的根基。好的...

4427
来自专栏数据小魔方

数据地图系列13|PowerBI

今天要跟大家分享数据地图系列的第13篇——PowerBI。 PowerBI是微软公司数据可视化系列集成的桌面端产品。(上一篇讲了个PowerMap,那个是Pow...

4606
来自专栏喵了个咪的博客空间

IOT设备通讯协议MQTT

哈喽大家好呀!笔者的公司最近在做IOT设备相关的业务,基于这个契机寻找学习了一下关于IOT通讯协议相关的内容,最终在技术选型上选择了使用MQTT协议并且结合EM...

5014
来自专栏NetCore

C/S结构和b/s结构的比较

随着软件系统的规模和复杂性的增加 ,软件体系结构的选择成为比数据结构和算法的选择更为重要的因素 ,三层客户/服务器体系结构为企业资源规划的整合提供了良好的框架 ...

2699

扫码关注云+社区

领取腾讯云代金券