in 网站建设
关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9


本文首发于 ayqy.net ,原文链接:http://www.ayqy.net/blog/%E5%...

零.从 Monolithic application 说起

Monolith means composed all in one piece. The Monolithic application describes a single-tiered software application in which different components combined into a single program from a single platform.

(摘自Introduction to Monolithic Architecture and MicroServices Architecture

把软件应用的不同组件都放到一个程序中,就叫 Monolithic application。例如,通过编程语言的基本特性将应用划分成类、函数和命名空间,用部署流水线来保证变更都经过测试后才部署到生产环境,并通过负载均衡机制运行多个实例,将其进行横向扩展:

All your logic for handling a request runs in a single process, allowing you to use the basic features of your language to divide up the application into classes, functions, and namespaces. With some care, you can run and test the application on a developer's laptop, and use a deployment pipeline to ensure that changes are properly tested and deployed into production. You can horizontally scale the monolith by running many instances behind a load-balancer.

在这种架构模式下,应用程序也能很好地工作,但存在 2 个问题:



Microservices are a software development technique—a variant of the service-oriented architecture (SOA) architectural style that structures an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.



Building applications as suites of services. As well as the fact that services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages. They can also be managed by different teams.


微服务与 SOA

Service-oriented architecture (SOA) is a style of software design where services are provided to the other components by application components, through a communication protocol over a network.

(摘自Service-oriented architecture

SOA 中,服务由应用程序组件通过网络通信协议提供给其它组件。因此,微服务架构算是 SOA 的一种变体,或者说是特例,特指满足某些特征的 SOA 设计

二.微服务架构的 9 大特征

通过服务进行组件化(Componentization via Services)


Our definition is that a component is a unit of software that is independently replaceable and upgradeable. There's been a desire to build systems by plugging together components, much in the way we see things are made in the physical world.

在微服务架构中,组件就是服务,通过 Web 服务请求或 RPC 之类的机制通信。这种服务粒度的组件化方式有 2 点优势:



但比起进程内调用,RPC 的性能成本更高,因此 RPC 接口大多是粗粒度的,也往往更难使用。另一方面,如果想要调整组件职责的话,重构成本也更高

围绕业务功能来组织团队(Organized around Business Capabilities)




Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. -- Melvyn Conway, 1967


A smart team will optimise around this and plump for the lesser of two evils - just force the logic into whichever application they have access to.

比起在 Monolithic application 中按业务线划分团队,以服务为边界更清晰、约束力也更强。因为很容易出现跨越模块边界的业务功能,而服务边界相对稳固一些

做产品而不是做项目(Products not Projects)


Microservice proponents tend to avoid this model, preferring instead the notion that a team should own a product over its full lifetime.


There is an on-going relationship where the question is how can software assist its users to enhance the business capability.

智能端点和傻瓜式管道(Smart endpoints and dumb pipes)

通信机制上,一个典型的例子是企业服务总线(Enterprise Service Bus),消息都流经 ESB,由 ESB 负责消息路由、编排、转换以及业务规则的应用,随后到达端点(endpoints)进行处理。这种模式下,端点可以保持傻瓜式,因为很多逻辑都在 ESB 消息管道里处理了。因此,称之为智能管道和傻瓜式端点(smart pipes and dumb endpoints)

而微服务倾向于相反的做法,智能端点和傻瓜式管道(smart endpoints and dumb pipes):

That the lanes of communication should be stripped of business processing and logic and should literally only distribute messages between components. It's then the components themselves that do processing / logic / validation etc... on those messages.


去中心化技术治理(Decentralized Governance)


Experience shows that this approach is constricting - not every problem is a nail and not every solution a hammer, we prefer using the right tool for the job.



We don’t end up with 20 different languages in the same system because each of them is opinionated and brings their own vision inside the system, maintaining different ecosystem is very expensive and potentially confusing without providing too many benefits.


But a trade-off could help out, having a limited list of languages or frameworks we can pick from can really help. Suddenly, we are not tightly coupled with one stack only.

去中心化数据管理(Decentralized Data Management)


应对这种情况的有效措施是领域驱动设计(Domain-Driven Design)中的界限上下文(Bounded Context):


(摘自初窥 Bounded Context


DDD divides a complex domain up into multiple bounded contexts and maps out the relationships between them.


Microservices prefer letting each service manage its own database, either different instances of the same database technology, or entirely different database systems - an approach called Polyglot Persistence.

P.S.对于去中心化数据存储带来的数据一致性问题,可以考虑通过一些补偿操作来让数据最终达到一致,具体见Starbucks Does Not Use Two-Phase Commit

基础设施自动化(Infrastructure Automation)

与 Monolithic application 相比,微服务的部署要更复杂一些。因为在复杂的网络环境中,部署多个服务比部署一个独立应用更困难:


容错设计(Design for failure)


A consequence of using services as components, is that applications need to be designed so that they can tolerate the failure of services. Any service call could fail due to unavailability of the supplier, the client has to respond to this as gracefully as possible.

比起 Monolithic application,这种容错设计带来的额外复杂性算是一种劣势


P.S.关于容错设计的更多信息,见Fault Tolerance in a High Volume, Distributed System

演进式设计(Evolutionary Design)


The key property of a component is the notion of independent replacement and upgradeability.


Change control doesn't necessarily mean change reduction - with the right attitudes and tools you can make frequent, fast, and well-controlled changes to software.




It's hard to figure out exactly where the component boundaries should lie.


Evolutionary design recognizes the difficulties of getting boundaries right and thus the importance of it being easy to refactor them. But when your components are services with remote communications, then refactoring is much harder than with in-process libraries.


Another issue is If the components do not compose cleanly, then all you are doing is shifting complexity from inside a component to the connections between components. Not just does this just move complexity around, it moves it to a place that's less explicit and harder to control.


It's easy to think things are better when you are looking at the inside of a small, simple component, while missing messy connections between services.


关注公众号【好便宜】( ID:haopianyi222 ),领红包啦~
腾讯云,良心云,价格优惠: https://t.cn/AieHwwKl
搬瓦工,CN2 GIA 优质线路,搭梯子、海外建站推荐: https://t.cn/AieHwfX9
Comments are closed.