大家觉得现在的微服务架构最需要什么?


传统的SOA的中心是ESB,统一做消息的转发和转换,当然ESB本身的中心化结构会带来单点问题和性能问题。

微服务在各个节点上可以用Docker来启动服务本身,然后外部引入ZooKeeper或者etcd这样的服务发现机制。当然,目前而言Docker的持久化层还需要加强。

那么,对于一个组织或者说开发者来说,创建微服务架构的技术痛点在哪里呢?是否对应用开发者自身要求(抽象能力、组织能力)比较高?

目前而言,在软件通信的各个设计中,我最喜欢的是UNIX的管道,简单、高效、兼容一切,把所有数据都认为是一个文件流而组合了所有的程序。但在现代系统中,已经很难看到这么简洁明快的设计了。所以我想是否有一种方式,能让分布式系统中的程序通信达到unix管道这样的高度?
已邀请:

yongfeng - 混技术圈的产品经理

赞同来自: shlallen hellogirl 思考zhe 徐磊 歪脖贰点零


发表几点自己的看法:
1. 从行业现状来看,在整个中国的IT生态中,集中式架构还是主流。分布式架构目前主要是互联网行业用的比较多。相对总的来说,占比还是比较小。而微服务,基本上也就是搞分布式架构的一小拨人开始去尝试的新鲜技术。从这个现状来看,新的思维方式,架构人才永远是痛点。很多人连互联网行业常用的分布式架构尚未理解,让它设计或者在生产实践中采用微服务架构。就勉为其难了。即使架构师具备了这种能力,但是负责具体实施的工程师团队是否有这种思维和类似的设计能力,就是一个很大的疑问。因此必然出现了目前只是在一些大的公司,小范围的实践。
2. 从微服务的运行载体来看,微服务架构的普及,依赖Docker等基于容器的技术在生产领域的大规模普及。微服务的思想,其实在之前的SOA的架构就萌发了,但是那事面向服务的思想,而少了一个“微”字。服务内部,依然是一个大杂烩。微服务,有点像原子,没有办法再进行切割。其核心的思想是每一个微服务的实体就是一个小的自治系统。这个实体不依赖其他的实体而独立存在,运行。它能快速的创建,也能快速的销毁。能够相互组合,也能快速拆散。容器技术,为这种“原子”提供了一个很好的执行载体。而Docker技术,就是他们相互组合的粘合剂。但是,从目前的现状来看,Docker在生产领域还尚未有大规模应用。这也是微服务技术无法大规模普及的原因之一。
3. 再者,微服务架构,和一个公司的研发团队的组织架构也有关系。如果一个公司,其团队按照服务进行划分,彼此松散耦合,就很容易践行这种微服务架构。如果按照职能进行划分,所谓的按照设计,前端,后台,测试,运维等划分,这种微服务架构,就很难玩的转。

[已注销]

赞同来自: 难易 hellogirl


其实整个Docker生态体系的为微服务架构是有点像UNIX的管道的,可以说 REST API == 管道,JSON == 文件流。有go语言的支撑,同样的简单,高效,兼容一切。那么难点在哪?我感觉实在最初的设计上。API怎么设计? 暴露那些功能 ? 路径怎么规范? 数据结构(JSON)怎么定义? 怎么技能保证高效又能不失可扩展性? 当整个服务体系不断扩大的时候,最初的设计还能够用多久而不需要大改?

田浩浩 - wizmacau developer

赞同来自: 难易 hellogirl


最需要的是DEMO吧。

对微服务研究不深,做一些简单的引用吧

Docker如何在微服务中使用

最基本的要素:
1. 基础镜像
2. 每个微服务的Dockerfile
3. 触发系统(CI)

从开发者的角度看微服务
巨型服务 与 微服务

Reference:
SOA还是微服务?
Docker开启微服务的未来

难易 - 华为杭州研究院PaaS开发者,http://my.oschina.net/HardySimpson/blog

赞同来自: hellogirl HeartArea


对,现在的微服务很麻烦,主要是管理起来麻烦

不过和传统的管道不一样,传统的管道里面启动的程序一般是一次性的
ls | grep aa

不过也有持久的
httpd & -o stdout | /tmp/aa.txt

我现在的想法是,微服务的依赖关系目前没有好的视觉化显示,如果一个东西不能被明确的表达出来就不会被明确的认知和管理

如果我提供一套微服务的注册服务,但不仅仅是API的暴露,而是把应用实体也囊括在里面,这样最后大家能看到的就是一个微服务的网状图,这个思路怎么样?

xiaolunsanguo - 京东商城-南京研发中心-JDOS团队

赞同来自: 难易 hellogirl


大型公司里面既有的业务和服务,转型为微服务的难点,我觉得并不是在服务的发现上。而是在“微”上。在传统的SOA里,也有UDDI这种类似于etcd的服务发现中心。但是难点在于服务转型为“微服务”。原先的许多业务方习惯了用大型号的物理机,动辄就是几十颗CPU,上百G的内存,上TB硬盘的服务器。当你劝说他转型为微服务,使用轻量级的容器,做成无状态的业务时,各种的不习惯和转变(包括从开发到运维的转变),都会阻碍接受“微服务”的理念。
当然,作为“微服务”的打造者,自身也不能一下子提供理想而完善的功能(毕竟需要版本的迭代和演进)。比如云硬盘、日志收集等。让很多业务和服务也不能一下子就接受“微服务”的改造。

shlallen - DaoCloud软件工程师,合伙人

赞同来自: xiaolunsanguo hellogirl


首先,我是相信微服务理念的一个人,这种理念或者方法论能为软件的开发,管理,运维带来很大的便利。

基于Docker的微服务,我觉得需要做的工作还有很多。

第一,如何做到“微”,分布式系统发展了十数年,的确也给行业带来了很多的便利,但是是否达到微服务的要求,这可能是架构师们需要考虑的地方。

第二,“微”是否就符合“微服务”的要求,其实还有其他的点需要考虑。比如,应用虽微,但是否适合Dockerize同样是一个大痛点。Docker希望应用有跨平台能力,和OS去耦,但是现实往往不是这样的。传统的分布式应用,应用本身的运行很依赖系统,虽然功能由应用本身提供,但是却借助内核或者系统服务。强行dockerize,增加容器复杂性的容器,后患不少。
当然这是架构师应该权衡的地方,到底是重构应用继续再“微”,还是强行入容器。这一点也是我认为企业实行微服务阻力最大的地方。

第三,可能就是大家特别关心的,发现机制是否完善,日志如何收集,统一的构建、运行、管理标准如何定义等。。。。

fsword - 程序员,搞java出身,喜欢ruby on rails、erlang和js,专注web 不相信中医理论 反对美化拔高传统文化 接受自由主义经济学观点,关注云计算和比特币

赞同来自: 难易 hellogirl


这个问题其实很好回答,现有的基础设施大都不是为微服务设计的,分为两类:
  1. 为所谓“单体”架构设计,比如 maven/bundle ,比如 Capistrano
  2. 为大规模分布式系统设计,比如 Google 系的一系列基础设施和它的社区模仿者


理解这两类情况以后就知道微服务需要什么了:

对第一类,工具和基础设施要扩展或重新设计,使之能够感知服务间协作关系。也可以保持本身不变,外围添加docker compose这样的编织系统。

对第二类,要尝试轻量级,或者提供SAAS性质的服务,使微服务所需要的配管、运维、测试工作能用相对较低的成本来实施。

最后说一句题外话,“管道”仅仅是各种架构风格的一种,并不是放之四海而皆准的,而且unix管道只是个不太完善的monad,不值得拿来做太多的期待

难易 - 华为杭州研究院PaaS开发者,http://my.oschina.net/HardySimpson/blog

赞同来自: xiaolunsanguo hellogirl


楼上这句话说的好

对第一类,工具和基础设施要扩展或重新设计,使之能够感知服务间协作关系。也可以保持本身不变,外围添加docker compose这样的编织系统。

现在的基础设施太差了,服务协作关系不明确,也就是说,在一套分布式系统上,一个应用是没办法简单的知道其他应用在哪里,在做什么。compose很好,但是是静态的,我对分布式系统的认知是,这是一个完全在线的多应用协作的网络,应用可以随时加入或者退出这个网络。热插拔。就像你可以往linux系统上简单的拷贝一个二进制程序然后运行起来。

oilbeater - 北大学渣@灵雀云

赞同来自:


泻药!

这方面经验不是太多说一点不成熟的看法。

第一到底怎样的粒度才合适。以一个 lnmp 架构来说是把 nmp 都分开好还是组合提供好?

第二微服务之间的接口如何能固定。很多 docker 官方镜像之间 link 都会有环境变量命名不一致的情况,真正到复杂的多服务系统,naming 的问题如何解决?

要回复问题请先登录注册