×

微服务架构的优缺点 微服务

微服务优点?微服务容器平台面对大数据存储是怎么做的

admin admin 发表于2022-07-04 15:04:24 浏览134 评论0

抢沙发发表评论

微服务优点


微服务是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关的 API(例如 REST)集相互通讯,且每个服务可以被单独部署,在微服务软件架构风格概念被提出来的初期,它具备以下三个核心特点:

1. 微服务为大型系统而生。 通常我们在系统架构设计上面临的问题都与系统的大小相关,随着业务的快速增长,会带来系统流量压力和复杂度的上升,系统的可维护性和可扩展性成为架构设计的主要考虑因素,微服务架构设计理念通过小而美的业务拆分,通过分而自治来实现复杂系统的优雅设计实现。

2. 微服务架构是面向结果的。 微服务架构设计风格的产生并非是出于学术或为标准而标准的设计,而是在软件架构设计领域不断演进过程中,面对实际工业界所遇到问题,而出现的面向解决实际问题的架构设计风格。

3. 专注于服务的可替代性来设计。 微服务架构设计风格核心要解决的问题之一便是如何便利地在大型系统中进行系统组件的维护和替换,且不影响整体系统稳定性。微服务带来的好处
独立的可扩展性,每个微服务都可以独立进行横向或纵向扩展,根据业务实际增长情况来进行快速扩展;

独立的可升级性,每个微服务都可以独立进行服务升级、更新,不用依赖于其它服务,结合持续集成工具可以进行持续发布,开发人员就可以独立快速完成服务升级发布流程;

易维护性,每个微服务的代码均只专注于完成该单个业务范畴的事情,因此微服务项目代码数量将减少至IDE可以快速加载的大小,这样可以提高了代码的可读性,进而可以提高研发人员的生产效率;

语言无关性,研发人员可以选用自己最为熟悉的语言和框架来完成他们的微服务项目(当然,一般根据每个公司的实际技术栈需要来了),这样在面对新技术或新框架的选用时,微服务能够更好地进行快速响应;

故障和资源的隔离性,在系统中出现不好的资源操作行为时,例如内存泄露、数据库连接未关闭等情况,将仅仅只会影响单个微服务;

优化跨团队沟通,如果要完全实践微服务架构设计风格,研发团队势必会按照新的原则来进行划分,由之前的按照技能、职能划分的方式变为按照业务(单个微服务)来进行划分,如此这般团队里将有各个方向技能的研发人员,沟通效率上来说要优于之前按照技能进行划分的组织架构;

原生基于“云”的系统架构设计,基于微服务架构设计风格,我们能构建出来原生对于“云”具备超高友好度的系统,与常用容器工具如Docker能够很方便地结合,构建持续发布系统与IaaS、PaaS平台对接,使其能够方便的部署于各类“云”上,如公用云、私有云以及混合云。

微服务容器平台面对大数据存储是怎么做的


整体而言,大数据平台从平台部署和数据分析过程可分为如下几步:
1、linux系统安装
一般使用开源版的Redhat系统--CentOS作为底层平台。为了提供稳定的硬件基础,在给硬盘做RAID和挂载数据存储节点的时,需要按情况配置。例如,可以选择给HDFS的namenode做RAID2以提高其稳定性,将数据存储与操作系统分别放置在不同硬盘上,以确保操作系统的正常运行。

2、分布式计算平台/组件安装
目前国内外的分布式系统的大多使用的是Hadoop系列开源系统。Hadoop的核心是HDFS,一个分布式的文件系统。在其基础上常用的组件有Yarn、Zookeeper、Hive、Hbase、Sqoop、Impala、ElasticSearch、Spark等。
先说下使用开源组件的优点:1)使用者众多,很多bug可以在网上找的答案(这往往是开发中最耗时的地方)。2)开源组件一般免费,学习和维护相对方便。3)开源组件一般会持续更新,提供必要的更新服务『当然还需要手动做更新操作』。4)因为代码开源,若出bug可自由对源码作修改维护。
再简略讲讲各组件的功能。分布式集群的资源管理器一般用Yarn,『全名是Yet Another Resource Negotiator』。常用的分布式数据数据『仓』库有Hive、Hbase。Hive可以用SQL查询『但效率略低』,Hbase可以快速『近实时』读取行。外部数据库导入导出需要用到Sqoop。Sqoop将数据从Oracle、MySQL等传统数据库导入Hive或Hbase。Zookeeper是提供数据同步服务,Yarn和Hbase需要它的支持。Impala是对hive的一个补充,可以实现高效的SQL查询。ElasticSearch是一个分布式的搜索引擎。针对分析,目前最火的是Spark『此处忽略其他,如基础的MapReduce 和 Flink』。Spark在core上面有ML lib,Spark Streaming、Spark QL和GraphX等库,可以满足几乎所有常见数据分析需求。
值得一提的是,上面提到的组件,如何将其有机结合起来,完成某个任务,不是一个简单的工作,可能会非常耗时。

3、数据导入
前面提到,数据导入的工具是Sqoop。用它可以将数据从文件或者传统数据库导入到分布式平台『一般主要导入到Hive,也可将数据导入到Hbase』。

4、数据分析
数据分析一般包括两个阶段:数据预处理和数据建模分析。
数据预处理是为后面的建模分析做准备,主要工作时从海量数据中提取可用特征,建立大宽表。这个过程可能会用到Hive SQL,Spark QL和Impala。
数据建模分析是针对预处理提取的特征/数据建模,得到想要的结果。如前面所提到的,这一块最好用的是Spark。常用的机器学习算法,如朴素贝叶斯、逻辑回归、决策树、神经网络、TFIDF、协同过滤等,都已经在ML lib里面,调用比较方便。

5、结果可视化及输出API
可视化一般式对结果或部分原始数据做展示。一般有两种情况,行熟悉展示,和列查找展示。在这里,要基于大数据平台做展示,会需要用到ElasticSearch和Hbase。Hbase提供快速『ms级别』的行查找。 ElasticSearch可以实现列索引,提供快速列查找。

平台搭建主要问题:
1、稳定性 Stability
理论上来说,稳定性是分布式系统最大的优势,因为它可以通过多台机器做数据及程序运行备份以确保系统稳定。但也由于大数据平台部署于多台机器上,配置不合适,也可能成为最大的问题。 曾经遇到的一个问题是Hbase经常挂掉,主要原因是采购的硬盘质量较差。硬盘损坏有时会到导致Hbase同步出现问题,因而导致Hbase服务停止。由于硬盘质量较差,隔三差五会出现服务停止现象,耗费大量时间。结论:大数据平台相对于超算确实廉价,但是配置还是必须高于家用电脑的。

2、可扩展性 Scalability
如何快速扩展已有大数据平台,在其基础上扩充新的机器是云计算等领域应用的关键问题。在实际2B的应用中,有时需要增减机器来满足新的需求。如何在保留原有功能的情况下,快速扩充平台是实际应用中的常见问题。

上述是自己项目实践的总结。整个平台搭建过程耗时耗力,非一两个人可以完成。一个小团队要真正做到这些也需要耗费很长时间。

目前国内和国际上已有多家公司提供大数据平台搭建服务,国外有名的公司有Cloudera,Hortonworks,MapR等,国内也有华为、明略数据、星环等。另外有些公司如明略数据等还提供一体化的解决方案,寻求这些公司合作对 于入门级的大数据企业或没有大数据分析能力的企业来说是最好的解决途径。

对于一些本身体量较小或者目前数据量积累较少的公司,个人认为没有必要搭建这一套系统,暂时先租用AWS和阿里云就够了。对于数据量大,但数据分析需求较简单的公司,可以直接买Tableau,Splunk,HP Vertica,或者IBM DB2等软件或服务即可。
-

微服务架构的优缺点


微服务在近几年大火,它具备了灵活部署、可扩展、技术异构等优点,但同时也带来了开发、运维的复杂性。是否要采用微服务架构需要根据系统的特点,结合企业的组织架构、团队能力等多个方面进行综合的判断,而不是为了微服务而微服务。例如基于微服务架构的MK-PaaS平台,通过将传统流程服务、组织服务、门户服务、消息服务、集成服务、生态组织、主数据等能力中台化;并提供统一集成&开发能力,整合生态服务能力。帮助大、中型组织高效构建内、外协作一体化的数字化平台,提高生态型组织的效率,提升业务敏捷度,夯实产业互联网&商业模式创新基座,赋能数字化转型升级,敏捷应对业务需求变化。
-微服务架构的优缺点