谈谈微服务

自从去年在一次上厕所的时候,翻开手机,看到微服务这一个概念,就认为这种架构的模式非常看好,自那以后,一直关注微服务相关的内容。目前微服务已经是一个非常火的概念,在Infoq几乎每条都有关于微服务的文章或者新闻。可见微服务已经像我们靠近。

微服务的“微”:

有一些观点体现在微服务的微在体现在代码量上,微服务的代码行数一定非常少。关于这个观点,个人并不认同,我觉得使用代码行数来衡量微服务的话,就像使用代码量来衡量一个软件开发工程师一样,都是不科学。

微服务的微体现在职责的单一上,这个个人非常认同,微服务就是职责单一的服务。就像面向对象设计中的单一职责一样,没有绝对的单一,职责的单一完全取决于对于业务的分析和理解。微服务可以设计像Unix那样简洁。服务前端开发者可以像写Unix Shell脚本一样开发应用。

微服务的好处

微服务的好处是显然意见的,微服务可以能够实现真正的敏捷,能够快速部署上线、能够具有很好的伸缩性、能够具有很好的扩展性。微服务还更容易形成积木,能够在产品的开发中,越跑越快。

微服务的挑战

微服务对基础服务设施的挑战。既然微服务的职责单一,那么就将要面对一个网站可能有成千上万个微服务。那么如何管理好微服务、以及微服务之间如何实现高速的通信、如何让开发者非常方便的调用微服务。如何建立完善的发布系统,能够实现快速上线。当然这些问题,目前已经有很多框架来解决。

微服务对开发者的挑战。微服务的团队一般按业务划分的,一个人负责一个服务或者一个人负责多个服务。那么微服务开发者,需要是一个全栈开发工程师,需要具备多种语言编程的能力、需要前后端的开发能力、需要运维知识、DBA知识。虽然目前技术发展非常快,而且越来越简单,但是成为一名全栈开发工程师,还是具有不少的挑战。

微服务与云计算2.0

目前的云计算主要是指服务器、CDN和各种数据存储的产品。未来的云计算将是一个微服务的库,这些微服务提供了很多的基础能力,比如消息队列、推送服务甚至抽象出了部分行业的基础业务服务。这也是我认为的云计算的一个发展趋势,目前也有这样的云计算公司。所以微服务也是未来云计算的一种方式。未来前端(服务前端)开发者可能就像今天写Unix的Shell脚本一样做应用开发。

期待成熟的微服务案例

目前微服务已经在社区里,提的非常多,而且各种关于微服务的新闻和技术文章、技术分享也非常多,但是目前还没有成熟的微服务案例。所以微服务还在发展初期,期待一个成功的微服务案例出现!

时间: 2024-10-06 00:31:11

谈谈微服务的相关文章

谈谈微服务中的 API 网关(API Gateway)

转载至:http://www.cnblogs.com/savorboard/p/api-gateway.html 背景 我们知道在微服务架构风格中,一个大应用被拆分成为了多个小的服务系统提供出来,这些小的系统他们可以自成体系,也就是说这些小系统可以拥有自己的数据库,框架甚至语言等,这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用. 但是在UI上进行展示的时候,我们通常需要在一个界面上展示很多数据,这些数据可能来自于不同的微服务中,举

NET实现的DDD、CQRS与微服务架构

WeText项目:一个基于.NET实现的DDD.CQRS与微服务架构的演示案例 最近出于工作需要,了解了一下微服务架构(Microservice Architecture,MSA).我经过两周业余时间的努力,凭着自己对微服务架构的理解,从无到有,基于.NET打造了一个演示微服务架构的应用程序案例,并结合领域驱动设计(DDD)以及命令查询职责分离(CQRS)体系结构模式,对事件驱动的微服务系统架构进行了一些实战性的探索.现将自己的思考和收获整理成文,分享给大家. 微服务架构 在介绍源代码之前,我还

跟着小程来学微服务--微服务思想

前言 一直对微服务非常感兴趣,因为公司的架构改造正好有机会能够接触微服务,买来一些书,请教了很多微服务大牛同时自己也做了很多总结,写成了80页ppt,算是我对微服务的一个认识吧,微服务本身不同的人有不同的理解,而我就从我自己的角度来谈谈微服务是什么. 目前市面上的不少书或者不少相关文章写的都是框架的使用,或者架构的介绍,其实对于刚入门不久的同学来说很容易造成微服务就是一堆框架和组件的堆砌,于是今天我将从理论和实践的角度来说说微服务. 现代互联网的方向是当企业发展到一定规模后,一定是大规模.云计算

基于.NET CORE微服务框架 -谈谈surging的服务容错降级

一.前言 对于不久开源的surging受到不少.net同学的青睐,也受到.net core学习小组的关注,邀请加入.NET China Foundation以方便国内.net core开源项目的推广,我果断接受邀请加入了队伍进行互相交流学习,最近也更新了surging新的版本 更新内容: 1. Castle.Core 兼容性问题,下一版本会去除,解决部分用户第一次编译VS卡死问题2. 增加容错降级3. 路由容错重构,针对于失败重试和失败没有重试,失败回调,4.增加部分功能单元测试5. 升级支持.

谈谈我对微服务、SpringCloud、k8s、Istio的一些杂想

一.微服务与SOA "微服务"是一个名词,没有这个名词之前也有"微服务",一个朗朗上口的名词能让大家产生一个认知共识,这对推动一个事务的发展挺重要的,不然你叫微服务他叫小服务的大家很难集中到一个点上. 业界对微服务与SOA的区别争论比较多大多都是在微观上对比他们的区别什么微服务粒度更细啊.微服务没有ESB啊.微服务通讯相比SOA采用更轻量级的协议啊等等,但是从微观谈区别本身就有悖论, 这些区别只是微服务的一种"最佳实践"而已.我个人理解微服务与S

谈谈surging 微服务引擎 2.0的链路跟踪和其它新增功能

一.前言 surging是基于.NET CORE 服务引擎.初始版本诞生于2017年6月份,经过NCC社区二年的孵化,2.0版本将在2019年08月28日进行发布,经历二年的发展,已经全部攘括了微服务架构的技术栈,覆盖了从服务注册.服务发现.中间件.协议主机再到链路跟踪,并且制定了一套微服务的规则,形成了一套统一的规范.以下是surging的服务引擎架构图 上图Diagnostic能够实现把整个服务链路的各种信息采集到. 比如来源地址.远程地址.报错.执行时间.调用链路.协议类型以及参数全部采集

微服务架构的设计和实践-培训感悟

这两天(4月8号,9号)我有幸参加了极客邦的培训课程-微服务架构的设计和实践,能够面对面倾听58架构师-孙玄的亲身授课,个人也是感到非常的荣幸.两天的时间,来回于广州和深圳,虽然不能说自己的技术有了一个质的提升,但至少也是一次很好的交流体现,这一趟不白走! 身为一个技术小白(虽然个人也有四年的开发经验,但大多的技术只是知其然而不知其所以然,而且接触面太狭隘),此次学习最明显的感受是,如果你只会写软件代码,了解与某种语言相关的语法,框架以及架构包括技术,那你肯定会"死的很惨".作为软件行

微服务架构的两大解耦利器与最佳实践

这几年,微服务架构这个术语渐成热门词汇,但它不是一个全新架构,更不是一个包治百病的架构.那么,微服务架构究竟能够解决什么问题,又带来哪些痛点? 本文将与大家谈谈这个问题,以及微服务架构的两大解耦利器配置中心和消息总线的最佳实践. 微服务架构解决的问题与带来的痛点 一 互联网高可用架构为什么要服务化? 上图是互联网典型的高可用架构,大部分公司如果没有使用微服务,正在使用这样的架构: 用户端是浏览器 browser,APP 客户端 后端入口是高可用的 nginx 集群,用于做反向代理 中间核心是高可

从 Spring Cloud 开始,聊聊微服务架构实践之路

[编者的话]随着公司业务量的飞速发展,平台面临的挑战已经远远大于业务,需求量不断增加,技术人员数量增加,面临的复杂度也大大增加.在这个背景下,平台的技术架构也完成了从传统的单体应用到微服务化的演进. 系统架构的演进过程 单一应用架构(第一代架构) 这是平台最开始的情况,当时流量小,为了节约成本,并将所有应用都打包放到一个应用里面,采用的架构为 .NET SQL Server: 表示层:位于最外层(最上层),最接近用户.用于显示数据和接收用户输入的数 据,为用户提供一种交互式操作的界面,平台所使用