Service-Disoriented Architecture

http://bravenewgeek.com/service-disoriented-architecture/

“You can have a second computer once you’ve shown you know how to use the first one.” -Paul Barham （只有当你知道如何能利用一台计算机的时候，才能去使用第二台计算机）

The first rule of distributed systems is don’t distribute your system until you have an observable reason to. Teams break this rule on the regular. People have been talking about service-oriented architecture for a long time, but only recently have microservices been receiving the hype.（分布式系统一条准则就是尽可能不要分布式，除非有非常强烈的理由。尽管如此大多数团队依然置之不理。过去人们对SOA谈得太多，近期则是因为microservice(MS)收到高度关注）

The problem, as Martin Fowler observes, is that teams are becoming too eager to adopt a microservice architecture without first understanding the inherent overheads. A contributing factor, I think, is you only hear the success stories from companies who did it right, like Netflix. However, what folks often fail to realize is that these companies—in almost all cases—didn’t start out that way. There was a long and winding path which led them to where they are today. The inquote of this, which some refer to as microservice envy, is causing teams to rush into microservice hell. I call this service-disoriented architecture (or sometimes disservice-oriented architecture when the architecture is DOA). （太多团队过于急切地尝试MS而没有先去了解overhead. 我们听到太多使用MS成功的案例比如Netflix, 但是却没想到这些公司再在开始阶段却并没有使用MS，而是之后发展过程中逐渐进化过来的。对于MS的羡慕导致太多团队过早地陷入MS hell）

The term “monolith” has a very negative connotation—unscalable, unmaintainable, unresilient. These things are not intrinsically tied to each other, however, and there’s no reason a single system can’t be modular, maintainable, and fault tolerant at reasonable scale. It’s just less sexy. Refactoring modular code is much easier than refactoring architecture, and refactoring across service boundaries is equally difficult. Fowler describes this as monolith-first, and I think it’s the right approach (with some exceptions, of course).（monolith听上去有非常负面的含义，意味着unscalable, unmaintainable, unresilient. 但是实施上上面三个特性并不是内在关联的，对于一个monolithic系统完全有可能做到模块化，可维护以及在一定规模上容错，只不过听上不并不是那么sexy. 此外它还有一些好处，我们可以很容易进行重构，很容易修改多个模块交互接口等。事实上monolith-first是一个正确的开发方式）

Don’t even consider microservices unless you have a system that’s too complex to manage as a monolith. The majority of software systems should be built as a single monolithic application. Do pay attention to good modularity within that monolith, but don’t try to separate it into separate services.

Service-oriented architecture is about organizational complexity and system complexity. If you have both, you have a case to distribute. If you have one of the two, you might have a case (although if you have organizational complexity without system complexity, you’ve probably scaled your organization improperly). If you have neither, you do not have a case to distribute. State, specifically distributed state, is hell, and some pundits argue SOA is satan—perhaps a necessary evil. （SOA是用来解决组织复杂性和系统复杂性的。如果同时有两种复杂性，那么有必要distribute. 如何只有一种比如组织复杂性，那么你完全可以通过从组织方向上解决问题而避免distribute. 如果两者都没有，那么完全没有必要distribute）

There are a lot of motivations for microservices: anti-fragility, fault tolerance, independent deployment and scaling, architectural abstraction, and technology isolation. When services are loosely coupled, the system as a whole tends to be less fragile. When instances are disposable and stateless, services tend to be more fault tolerant because we can spin them up and down, balance traffic, and failover. When responsibility is divided across domain boundaries, services can be independently developed, deployed, and scaled while allowing the right tools to be used for each.（MS各种优点）

We also need to acknowledge the disadvantages. Adopting a microservice architecture does not automatically buy you anti-fragility. Distributed systems are incredibly precarious. We have to be aware of things like asynchrony, network partitions, node failures, and the trade-off between availability and data consistency. We have to think about resiliency but also the business and UX implications. We have to consider the boundaries of distributed systems like CAP and exactly-once delivery.（MS缺点可以从分布式系统复杂性上来理解）

When distributing, the emphasis should be on resilience engineering and adopting loosely coupled, stateless components—not microservices for microservices’ sake. We need to view eventual consistency as a tool, not a side effect. The problem I see is that teams often end up with what is essentially a complex, distributed monolith. Now you have two problems. If you’re building a microservice which doesn’t make sense outside the context of another system or isn’t useful on its own, stop and re-evaluate. If you’re designing something to be fast and correct, realize that distributing it will frequently take away both.(分布式应该尽可能地关注弹性，解耦，以及无状态，而不是MS，否则最终结果就是为了MS而作出一个复杂的分布式的monolithic系统(service-disoriented architecture))

Like anti-fragility, microservices do not automatically buy you better maintainability or even scalability. Adopting them requires the proper infrastructure and organization to be in place. Without these, you are bound to fail. In theory, they are intended to increase development velocity, but in many cases the microservice premium ends up slowing it down while creating organizational dependencies and bottlenecks.（MS需要团队已经有良好（相对稳定）的架构以及组织，否则就会降低团队开发速度）

There are some key things which must be in place in order for a microservice architecture to be successful: a proper continuous-delivery pipeline, competent DevOps and Ops teams, and prudent service boundaries, to name a few. Good monitoring is essential. It’s also important we have a thorough testing and integration story. This isn’t even considering the fundamental development complexities associated with SOA mentioned earlier.（MS还需要：持续集成部署的pipeline, 高效的DevOps/Ops团队，考虑周全的service边界，良好监控，以及完全的测试和集成等等。也就是说除非是结构和技术相对比较稳定的公司，否则采用MS很难达到预期效果）

The better strategy is a bottom-up approach. Start with a monolith or small set of coarse-grained services and work your way up. Make sure you have the data model right. Break out new, finer-grained services as you need to and as you become more confident in your ability to maintain and deploy discrete services. It’s largely about organizational momentum. A young company jumping straight to a microservice architecture is like a golf cart getting on the freeway.（最好的策略应该是bottom-up. 首先构建monolith系统或者是几个比较粗粒度的服务，当数据模型稳定之后然后拆分成为细粒度的服务，同时要确保有能力来维护和部署这些细粒度服务。大部分时候采用MS是因为组织结构复杂所驱使的。一个年轻公司上来直接采用MS就好像让一辆高尔夫球车开上高速）

Microservices offer a number of advantages, but for many companies they are a bit of a Holy Grail. Developers are always looking for a silver bullet, but there is always a cost. What we need to do is minimize this cost, and with microservices, this typically means easing our way into it rather than diving into the deep end. Team autonomy and rapid iteration are noble goals, but if we’re not careful, we can end up creating an impedance. Microservices require organization and system maturity. Otherwise, they end up being a premature architectural optimization with a lot of baggage. They end up creating a service-disoriented architecture.（MS有许多优点但是对于许多公司来说更像是个圣杯。开发人员总是在寻找silver bullet但是这是有代价的，我们要做的就是减少这个代价，对MS来说就是要找到一条比较很容易采用MS的方法而不是一头就扎进去。team自组织以及快速迭代是非常诱人，但是一不小心我们就可能创造一个阻力。采用MS以组织和系统相对稳定成熟为前提的，否则就成为一个带着重重包袱进行的premature架构优化）