微服务架构概述 架构模式( 二 )


有了微服务,每个服务都可以根据需求和业务使用不同的技术或语言实现 。任何改变服务技术/语言的决定只需要重写具体的服务,因为所有的微服务都是相互独立的 。
3.8支持微服务的正确工具/技术的可用性
几年前,我们没有合适的工具和技术来支持微服务 。但是由于Docker容器和云基础设施(尤其是PaaS)向公众提供服务,微服务正在被大规模采用 , 因为它们提供了我们需要的“自由”,而不需要传统的配置过程 。
4.了解微服务摘要4.1微服务架构的优势
每个服务都足够内聚小,代码简单易懂 , 开发效率高 。
服务可以直接独立部署,使连续部署成为可能 。
每个服务都可以水平和垂直扩展,并且每个服务都可以根据需要部署到适当的硬件和软件 。
扩展开发团队很容易,可以按照每个组件来组织 。
提高容错能力 , 一个服务的问题不会让整个系统瘫痪 。
该系统在很长一段时间内都不会局限于一个技术栈 。
降低成本 。尽量重用现有功能,避免重复制作轮子 。可以大大降低项目建设过程的研究、设计、开发、测试、运营和维护的成本 。
易开发易维护:一个微服务只关心一个具体的业务功能,所以业务清晰 , 代码少 。独立开发和部署服务 。
本地修改很容易,所以开发在线速度和灵活性 。
更高的代码质量
围绕业务功能创建/组织代码 。
提高生产力 。开发者专攻自己的微服务开发,熟悉业务和代码 。
更易于扩展
技术栈不受限制:每个服务可以使用不同的开发语言 。
按需扩展:可以根据不同的需求实现细粒度的扩展 。
打好多端服务的基础(多客户端,如浏览器、车载终端、Android、IOS等 。).
应用程序的持续集成和持续交付极大地提高了生产力 。要提高开发者的生产力 , 开发者只需要将代码推送到代码仓库即可 。代码将被集成、测试、部署、重新测试、与基本功能(Maven依赖项)合并、质量审查,并准备好以极大的信心进行部署 。减少了人工操作,大大提高了重复工作的效率 。
4.2微服务的缺点
操作和维护的技术复杂性以及相应的操作和维护成本(测试、变更、部署)
必须建立开发运维一体化机制Devops 。
必须有完整的监控手段和自动恢复手段 。
【微服务架构概述 架构模式】数据库分区引起的业务数据同步和一致性问题
微服的界面会成为变化的敏感点(尽量保持界面稳定,不要频繁改变参与和参与) 。
对运维要求高:服务意味着更多的运维投入 。单个应用只需要保证一个应用的正常运行,而在微服务中,需要保证几十个、几百个服务的正常运行和协同工作 。服务越小 , 独立性越好 , 但对应的服务数量越大 。每个服务都需要独立的配置、部署、监控、日志收集等 。,成本呈指数级增长 。需要更高的自动化运维策略 。
微服务应用作为一个分布式系统,带来了复杂性 。当应用是一个整体应用时,模块之间的调用都是在应用内部,即使进行分布式部署 , 也仍然是在应用内部调用 。但是微服务是多个独立的服务,模块调用的时候分发会比较麻烦 。
对于多个独立的数据库,事务的实现更具挑战性 。
依赖性管理是复杂的,
测试微服务变得复杂 。当一个服务依赖于另一个服务时,测试需要另一个服务的支持 。
5.微服务5.1微服务功能直观体验 。
微服务实现了以下功能:为vue开发的小程序和h5页面提供数据接口(即HTTP的访问地址) , 可以查询编程语言的服务 。实现了以下微服务接口:
通过筛选条件查询:https://localhost:8888/v2/vue/api/programLanguage/getByName?language_name=P 返回:["PHP","Python"] 无条件的全量查询:https://localhost:8888/v2/vue/api/programLanguage/getAll 返回:["C","vue","java","PHP","Python","C++"] 另外一种条件查询方式:https://localhost:8888/v2/vue/api/programLanguage/getdetail/C 返回:{"laguage_name":"C","star_number":10,"desc":"万物之源C语言 。C语言于1969年至1973年之间由AT&T公司旗下贝尔实验室创建完成,用于构建Unix操作系统 。C语言是一种通用型命令式计算机编程语言 , 其支持结构化编程、词汇变量范围与递归,同时亦是套能够预防各类未预期操作的静态类型系统 。其最初构建目标在于编写系统软件 。"}
5.2代码示例
以第一个接口https://localhost:8888/v2/vue/API/program language/get by name的代码为例 。

推荐阅读