Redian新闻
>
请教:ChIP抗体的dilution
avatar
请教:ChIP抗体的dilution# Biology - 生物学
c*y
1
点击借记卡之后为什么跳到了中信银行的主页呢?
家人没有中信的卡,只有工商银行的卡,请问怎么操作呢?
父母在小城市,没中信,总不能连缴费都要跑一趟吧。
破网站都快把大肚婆气疯了!
avatar
m*d
3
我在ChIP RNA Pol II, 然后qPCR定量某基因promoter region及gene body的 RNA Pol
II loading,以判断此基因转录是否在某些treatment下被激活
我试了abcam的 RNA Pol II antibody (ab817),效果还挺好的,我每个reaction(10cm
plate,80%confluent)都加10microlitter Ab,想问问版上常做这个assay的前辈,大
家都用什么样的antibody dilution,像我这么做着实太费抗体了
avatar
l*r
4
借记卡不清楚如何操作。
另外一种办法是请国内的亲戚朋友帮忙去中信的ATM缴费,需要把drop off letter和护
照第一页的信息给帮忙缴费的人,缴完了,对方把收据号码给你就好。
avatar
N*r
5
我觉得就是类似微内核那套东西,或者所谓的unix哲学
简单的说,就是所有的功能都break down成最小化功能的程序,然后之间通过标准接口
传送数据互相通讯
如果我记得不错,这就是amazon在十几年前就在做的事情,实在没有什么新意
实际上工程里最难的是如何把一个大工程分解为相对独立的小项目,但微服务不谈这个
,只谈为什么分解了之后会好
所以
天底下没有新鲜事情
avatar
k*n
6
如果就qpcr的话,2,000,000个细胞+2-5ul抗体足够了
avatar
g*9
7
人多活少玩这个行,否则维护就是个大问题。另外一个优点是high available,load
balancing, monitoring都做在framework里面了。但是缺点是性能,数据量大了就不
一定适用了。

【在 N*****r 的大作中提到】
: 我觉得就是类似微内核那套东西,或者所谓的unix哲学
: 简单的说,就是所有的功能都break down成最小化功能的程序,然后之间通过标准接口
: 传送数据互相通讯
: 如果我记得不错,这就是amazon在十几年前就在做的事情,实在没有什么新意
: 实际上工程里最难的是如何把一个大工程分解为相对独立的小项目,但微服务不谈这个
: ,只谈为什么分解了之后会好
: 所以
: 天底下没有新鲜事情

avatar
s*s
8
我自己没做过。不过实验室做chip-seq的时候,一般做几个浓度,
取pulldown DNA的量刚好plateau的浓度

Pol
10cm

【在 m**********d 的大作中提到】
: 我在ChIP RNA Pol II, 然后qPCR定量某基因promoter region及gene body的 RNA Pol
: II loading,以判断此基因转录是否在某些treatment下被激活
: 我试了abcam的 RNA Pol II antibody (ab817),效果还挺好的,我每个reaction(10cm
: plate,80%confluent)都加10microlitter Ab,想问问版上常做这个assay的前辈,大
: 家都用什么样的antibody dilution,像我这么做着实太费抗体了

avatar
q*n
9
见过做成microservice后latency 变差的, 因为以前调用library现在要用另外
service, 经过https, 即使Nginx再快网络再快, 也是慢了。
avatar
s*e
10
虽然经常把微服务挂在嘴边,但到了让我说出个所以然的时候,突然糊涂了。然后放狗
搜了吧,还是糊涂。
我司用过很多 Java 的牛B技术,从最早的EJB(至今觉得这个玩意儿就是一坨),然后
JMS,ESB,到现在在用的SOA,然后有开始炒微服务。
相信很多人都傻傻分不清 SOA 和 微服务的区别,我看了那么多资料,其实还是分不清
楚,反正能够糊弄人就行。
以下是我自己的观点,如果错误了,就当是个P,放过了 :-)
先过一下几个概念:
HTTP Service
HTTP 服务,在特定语境下和 HTTP API 等同
HTTP API
API 以 HTTP协议为基本载体,实现远程调用
RESTFul API
遵循Restful规范的 HTTP API
SOA
大型复杂基于HTTP的软件的架构方式,面向服务的架构,把各种软件功能,抽象成
HTTP 服务/API,这些服务通过SOA软件组合起来。这个架构中,有三个角色:
服务提供商
软件代理(SOA软件)
服务消费者
SOA软件,提供了很多额外的功能,用来简化服务自身的开发,比如,安全,版本控制
,服务组合和管理(Orchestration,governance)等等,SOA端还可集成ESB,MSG等各
种功能,同时
还兼做 LB,HA等等
Microservice
Microservice 本质上也是一种架构,把一个复杂基于HTTP的功能,按业务功能拆分成
若干子功能,每个子功能独立部署,多个子功能合并在一起,完成一个复杂的功能。
很显然, 在这个架构里只有两种角色:服务提供商和服务消费者
我个人觉得,SOA和Microservice最大的区别就是,Microservice没有【复杂的软件代
理】,特地断一下句,避免歧义。Micrsoservice可以通过HAProxy等代理,添加安全功
能等,但是不会做非常复杂的事情,比如组合、裁剪多个服务,构成另外的服务等。
在实践中,无论是SOA,Microservice,在分割开发功能时,一般都按业务功能进行
拆分,而不是按开发规模进行拆分,即有些服务很复杂,但必须作为整体开发,这种情
况下,称之为“微”服务不是很恰当。
举个自己这边实际的例子:
我们的APP 需要图片服务,包括上传(上传后解析exif内容,生产各种尺寸的缩略图,
并保存到指定文字),下载,通过"伪"文件名访问上传后的原图和各种尺寸的图片;需
要用户系统,我们使用Spring 独立开发了自己的Oauth 系统;还有App后端常规服务。
我们把 图片服务 和 Oauth 独立成了微服务,因为这两个功能比较单一,和App本身没
有太大关系,同时其他应用也需要使用类似的功能。为了简化部署,目前是通过
HAPROXY 做 LB,提供给APP后端调用,以后打算部署到OpenShift里,这样就省下很多
配置工作,简化了部署。
举这个列子,我是想说,微服务和PaaS有一种天然的亲密度。我司这边,在拼命把各种
服务迁徙到PaaS里,最后去掉昂贵,复杂,不牢靠的SOA。
现在有很多开源项目,非常激进,直接基于PaaS,推出微服务套件,把微服务的开发和
部署极端简化,简化到甚至几行代码的事情。
有兴趣的请参考我最近在学习的项目:fabric8.io
回到实践,我自己的感受是,1)没有啥架构是万能的,还是要因地制宜,微服务不是
万能,SOA也有自己的适用范围,2)避免教条主义,3)这个架构有时候和写代码类似
,不要死循环,真有这样的蠢人 :),4)不要多层嵌套,一般两层足矣
======================
另外统一回答私信我的朋友:
请不要私信我,我是潜水员,主要是时间紧,最近有些空才回贴。
我也不是大拿,除了大学毕业,没有系统学习过其他东西,都是书到用时才去看,主要
是放狗搜,然后看wiki和stackoverflow,先看懂概念,基本规范或语法,就开始做,碰
到具体问题就 Stack Overflow,没有武功秘籍。
所以,第一个找我做项目的人,我真心感谢他,并且说声对不起,我做的内东西比较烂
:)
avatar
g*t
11
我觉得和soa的区别就是microservice的
client/server或者service模型简单一致吧。就是数据格式和协议。
Http json
或者groc json/protobuf等等。
SoA的sevice 模型应该复杂的多。这microservice
还真是古代的东西的复活。不过不是Unix philosophy。
我觉得是cobol什么的,类似于用goto定义业务逻辑。
Service分成小块,那么连接的自由度就会很大。
就靠近goto的方法。SOA如果从high level看应该是受到结构化编程的影响。
不知我是不是表达清楚了。我们做以下类比:
一块程序
和另一块程序
互相作用有两个办法,
一个是goto
一个是这两个程序上套一个框。
就是结构化编程或者OO
现在功能模块互相作用也是这两个风格。
SOA看着像后者。
假如翻一下goto转成结构化的那篇古代论文。
应该可以发展出来把microservice refactor成一层一层
结构的技术。我感觉这里的数学部分是一样的。


: 虽然经常把微服务挂在嘴边,但到了让我说出个所以然的时候,突然糊涂
了。然
后放狗

: 搜了吧,还是糊涂。

: 我司用过很多 Java 的牛B技术,从最早的EJB(至今觉得这个玩意儿就是
一坨)
,然后

: JMS,ESB,到现在在用的SOA,然后有开始炒微服务。

: 相信很多人都傻傻分不清 SOA 和 微服务的区别,我看了那么多资料,其
实还是
分不清

: 楚,反正能够糊弄人就行。

: 以下是我自己的观点,如果错误了,就当是个P,放过了 :-)

: 先过一下几个概念:

: HTTP Service

: HTTP 服务,在特定语境下和 HTTP API 等同



【在 s******e 的大作中提到】
: 虽然经常把微服务挂在嘴边,但到了让我说出个所以然的时候,突然糊涂了。然后放狗
: 搜了吧,还是糊涂。
: 我司用过很多 Java 的牛B技术,从最早的EJB(至今觉得这个玩意儿就是一坨),然后
: JMS,ESB,到现在在用的SOA,然后有开始炒微服务。
: 相信很多人都傻傻分不清 SOA 和 微服务的区别,我看了那么多资料,其实还是分不清
: 楚,反正能够糊弄人就行。
: 以下是我自己的观点,如果错误了,就当是个P,放过了 :-)
: 先过一下几个概念:
: HTTP Service
: HTTP 服务,在特定语境下和 HTTP API 等同

avatar
s*m
12
microservice就是把一个大的系统分成若干个service,每个service仅仅负责一件事情
,service之间通过service interface,而不是reference library和function call调
用别的service。
优点
1)service可以足够小,几个人的小组就可以完全own。
2)loose couple.
3)灵活,比如可以加上现在正慢慢流行的service mesh
avatar
b*u
13
如果系统比较大,可以考虑在microservice之间加一个eventbus system,比如kafka之
类的。
这样系统就async了。

【在 g****t 的大作中提到】
: 首先感谢之前各位讨论restful API。
: 我相信这些实战中的知识对大家都很有益。
: 各位老司机能否谈下什么叫micro services?
: 为啥热门了?怎么做?
: ref
: https://docs.microsoft.com/en-us/azure/architecture/microservices/

avatar
w*y
14

干嘛要经过HTTPS?public走HTTPS,内部都走kafka好了,快多了。

【在 q******n 的大作中提到】
: 见过做成microservice后latency 变差的, 因为以前调用library现在要用另外
: service, 经过https, 即使Nginx再快网络再快, 也是慢了。

avatar
z*g
15
我瞎说一句,SOA是内部类似integration的东东,
microservice都是对外的。
我没搞错吧。
avatar
z*g
16
对啊,integration没听说走microservice的。

【在 w*********y 的大作中提到】
:
: 干嘛要经过HTTPS?public走HTTPS,内部都走kafka好了,快多了。

avatar
s*e
17
带Integration基本就是 SOA 或 ESB 之类的,microservice 一般不用直接用。
内部走HTTPS今后是个趋势,这些东西随着硬件性能提升,配置傻瓜化(DevOps),都
会配上。

【在 z*****g 的大作中提到】
: 对啊,integration没听说走microservice的。
avatar
s*e
18
Microservice 可以对内

【在 z*****g 的大作中提到】
: 我瞎说一句,SOA是内部类似integration的东东,
: microservice都是对外的。
: 我没搞错吧。

avatar
s*e
19
一般内部开发,都倾向于把独立功能做成一个单独的service,这个service可以是整个
Microservice 架构的一部分,也可以SOA的某个后端service。这个没有特别限定。

【在 g****t 的大作中提到】
: 我觉得和soa的区别就是microservice的
: client/server或者service模型简单一致吧。就是数据格式和协议。
: Http json
: 或者groc json/protobuf等等。
: SoA的sevice 模型应该复杂的多。这microservice
: 还真是古代的东西的复活。不过不是Unix philosophy。
: 我觉得是cobol什么的,类似于用goto定义业务逻辑。
: Service分成小块,那么连接的自由度就会很大。
: 就靠近goto的方法。SOA如果从high level看应该是受到结构化编程的影响。
: 不知我是不是表达清楚了。我们做以下类比:

avatar
s*e
20
microservice 这个词有问题,通常让人误解为一个 micro service,然后大家会纠结
,如何判断这个 service 是 micro :)
如果要讨论和 SOA 的区别,我觉得这样说比较清晰:
SOA - Service Oriented Architecture
MSA - Micro Service Architecture
在我自己的实际应用中,我们开发一个Service,总是按某个业务功能来做的,这个和
使用 SOA 还是 MSA 没有太大区别。
但是实际开发中,还是有些区别,主要体现在一些辅助性质的特性功能上,比如,安全
,授权,异步,metrics,监控等等。
SOA 做了很多这方面的处理,我们开发 SOA 的服务时,这些事情,一般不鼓励也不允
许做,都通过SOA来实现,这样就有一个中心化的控制。
MSA 这方面就比较少,当前都需要自己来做。
但是这个不是绝对。fabric8 就开始做了,感觉在一些地方,是个弱化版的SOA,在其
他方面,尤其是DevOps方面,又远远超过常规的SOA。给我的感觉就是一个简化的SOA+
DevOps tool chain。
avatar
s*e
21
这个好像很多人都这么用 :)

【在 b****u 的大作中提到】
: 如果系统比较大,可以考虑在microservice之间加一个eventbus system,比如kafka之
: 类的。
: 这样系统就async了。

avatar
c*v
22
Microservice 是相对完整的独立模块,不和别的microservice
共用辅助功能部分吧。这可能和多种语言都有廉价好用的开源工具有关。
这样Microservice 就可以几个人own一个端到端完整的功能模块。省了不少联合调试的
功夫?


: microservice 这个词有问题,通常让人误解为一个 micro service,然后大家
会纠结

: ,如何判断这个 service 是 micro :)

: 如果要讨论和 SOA 的区别,我觉得这样说比较清晰:

: SOA - Service Oriented Architecture

: MSA - Micro Service Architecture

: 在我自己的实际应用中,我们开发一个Service,总是按某个业务功能来做的,
这个和

: 使用 SOA 还是 MSA 没有太大区别。

: 但是实际开发中,还是有些区别,主要体现在一些辅助性质的特性功能上,比如
,安全

: ,授权,异步,metrics,监控等等。

: SOA 做了很多这方面的处理,我们开发 SOA 的服务时,这些事情,一般不鼓励
也不允



【在 s******e 的大作中提到】
: 这个好像很多人都这么用 :)
avatar
z*g
23
可以对内什么意思?
企业内网应用不是我说的对内的意思。我说对内是esb,soap,jms这种。

【在 s******e 的大作中提到】
: Microservice 可以对内
avatar
z*g
24
"内部走HTTPS今后是个趋势"
这个内部又是什么意思?
integration?
服务器和服务器之间?有啥意义?
证书怎么解决?
avatar
z*g
25
某些情况不用kafka,用reddis也行
avatar
t*h
26
简单理解:
MSA:
JSON,Encapsulated data, reactive/async
SOA:
wsdl/xml, Service bus, function calls
avatar
w*m
27
个人感觉是,microservice是正式员工contractor化。
相当于各人的责任田。
接口定义好,压力测试通过,就验收结单。原dev从此转为运营。
一个人负责一块,出了事找那个人就行了。
等到该dev跑路,招个新人重写就是了。
人走码废,应该是以后的大趋势。
avatar
g*t
28
总结的很好啊。受教了


: 简单理解:

: MSA:

: JSON,Encapsulated data, reactive/async

: SOA:

: wsdl/xml, Service bus, function calls



【在 t*******h 的大作中提到】
: 简单理解:
: MSA:
: JSON,Encapsulated data, reactive/async
: SOA:
: wsdl/xml, Service bus, function calls

avatar
g*t
29
人走码废。
这样马公市场可以常做常有啊。马公单独own 一块端到端的
完整功能模块,还可以万众创业。


: 个人感觉是,microservice是正式员工contractor化。

: 相当于各人的责任田。

: 接口定义好,压力测试通过,就验收结单。原dev从此转为运营。

: 一个人负责一块,出了事找那个人就行了。

: 等到该dev跑路,招个新人重写就是了。

: 人走码废,应该是以后的大趋势。



【在 w********m 的大作中提到】
: 个人感觉是,microservice是正式员工contractor化。
: 相当于各人的责任田。
: 接口定义好,压力测试通过,就验收结单。原dev从此转为运营。
: 一个人负责一块,出了事找那个人就行了。
: 等到该dev跑路,招个新人重写就是了。
: 人走码废,应该是以后的大趋势。

avatar
s*y
30
Microservice is SOA done right
Loose coupling, services have minimal dependency on each other
Do one thing, and do one thing well
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。