TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Developing Service Oriented Architectures

115 点作者 hachiya大约 11 年前

8 条评论

JeffJenkins大约 11 年前
If you&#x27;re considering switching your monolithic application into a SOA you should consider the testing and debugging implications seriously.<p>If your call graph goes more than one level deep then doing integration&#x2F;functional testing becomes much more complicated. You have to bring up all of the services downstream in order to test functionality which crosses that boundary. You also have to worry a lot more about different versions of services talking to each other and how to test&#x2F;manage that. The flip side is that the services will be much smaller, so leaf nodes in the call graph can reach a level of test coverage higher than a monolithic service.<p>Debugging and performance testing becomes more complicated because when something is wrong you now have to look at multiple services (upstream and downstream) in order to figure out where the cause of some bug or performance issue is. You also run into the versioning issue from above where you have a new class of bug caused by mismatched versions which either have tweaked interfaces or underlying assumptions that have changed in one but not the other (because the other hasn&#x27;t been deployed and those assumptions are in shared code). The bright side for debugging and performance is that once you know which service <i>is</i> causing the issue it&#x27;s way easier to find what inside the service is causing the issue. There&#x27;s a lot less going on, so it&#x27;s easier to reason about the state of servers.
评论 #7435197 未加载
noelwelsh大约 11 年前
Jay Kreps epic blog post on the Log should be required reading: <a href="http://engineering.linkedin.com/distributed-systems/log-what-every-software-engineer-should-know-about-real-time-datas-unifying" rel="nofollow">http:&#x2F;&#x2F;engineering.linkedin.com&#x2F;distributed-systems&#x2F;log-what...</a><p>We do things very differently to that discussed in the OP (and are heavily influenced by the Krepian school of SOA.) I&#x27;d write more, but I&#x27;m on a train with flaky internet.
评论 #7435141 未加载
adrianhoward大约 11 年前
For a slightly different slant on SOA&#x27;s I&#x27;d thoroughly recommend watching Fred George&#x27;s talk on the technical side of implementing micro-service architectures from Oredev last year<p><a href="https://vimeo.com/79866979" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;79866979</a><p>along with his talk on Programmer Anarchy which is more about the resulting team &#x2F; working patterns<p><a href="https://vimeo.com/79866978" rel="nofollow">https:&#x2F;&#x2F;vimeo.com&#x2F;79866978</a><p>It&#x27;s moved playing with much finer-grained service architectures <i>way</i> up my to to list.
评论 #7436427 未加载
评论 #7439474 未加载
contingencies大约 11 年前
Other big benefits you get from well defined interfaces include security - you can do application level firewalling, statistics, anomaly detection really easily - and testing (play back known traffic, literally generate every possible message and see what happens, etc.)<p>Also, HTTP can be a poor choice in security terms for its complexity baggage (cookies, headers, methods, DNS baggage, SSL baggage, etc.). Alternatives such as MQs can be useful to consider, especially at later points in growth, since they can handle complex topologies with ease.<p>I believe the author could benefit from making a distinction between stateful and stateless in his description of dumb and smart API clients, since state is the main factor resulting from assumptions here.
ndcrandall大约 11 年前
So after going back and forth with our startup on SOA or not, I have felt like separating these services out of (in our case) a monolithic Rails application has made sense. I would like to use Sinatra for one service, rails for the web interface, and possibly Python for the last service. I understand this adds a lot of overhead by creating an interface and authentication for each service.<p>For me the logical division of services seems to make sense especially when using &#x27;the right tool for the right job&#x27;<p>I may be over optimizing, but I think it will pay off at a later date with more developers and the need to scale each service separately. Maybe someone can point out issues with this thinking (besides those addressed in the blog post).
评论 #7435000 未加载
评论 #7435251 未加载
评论 #7436857 未加载
评论 #7436707 未加载
评论 #7435668 未加载
hartror大约 11 年前
#2 is exactly how I pitched a migration to a micro-service architecture to my CEO yesterday. Feeling rather pleased with myself right now.
zimpenfish大约 11 年前
Last job wanted SOA but wouldn&#x27;t deploy Rabbit (or any other message bus) because &quot;it&#x27;s another thing to look after&quot;. Ended up as a simple REST-alike webservice. Which I guess includes &quot;service&quot; in the description...
评论 #7435032 未加载
评论 #7435181 未加载
nl大约 11 年前
So.. SOA.<p>Is anyone doing SOA+ESB in a non-Enterprise environment?<p>Is an ESB actually useful beyond the idea that it is supposed to let &quot;non skilled&quot; people &quot;develop services&quot; (which I&#x27;m somewhat cynical about)?
评论 #7435423 未加载
评论 #7435162 未加载
评论 #7435210 未加载
评论 #7434893 未加载
评论 #7435300 未加载