微服务介绍 已翻译 100%

oschina 投递于 2015/05/20 06:16 (共 20 段, 翻译完成于 05-23)
阅读 13926
收藏 177
14
加载中

This is a guest post by Chris Richardson. Chris is the founder of the original CloudFoundry.com, an early Java PaaS (Platform-as-a-Service) for Amazon EC2. He now consults with organizations to improve how they develop and deploy applications. He also blogs regularly about microservices at http://microservices.io.

==============

Microservices are currently getting a lot of attention: articles, blogs, discussions on social media, and conference presentations. They are rapidly heading towards the peak of inflated expectations on the Gartner Hype cycle. At the same time, there are skeptics in the software community who dismiss microservices as nothing new. Naysayers claim that the idea is just a rebranding of SOA. However, despite both the hype and the skepticism, the Microservice architecture pattern has significant benefits – especially when it comes to enabling the agile development and delivery of complex enterprise applications.

This blog post is the first in a 7-part series about designing, building, and deploying microservices. You will learn about the approach and how it compares to the more traditional Monolithic architecture pattern. This series will describe the various elements of the Microservice architecture. You will learn about the benefits and drawbacks of the Microservice architecture pattern, whether it makes sense for your project, and how to apply it.

Let’s first look at why you should consider using microservices.

已有 1 人翻译此段
我来翻译

Building Monolithic Applications

Let’s imagine that you were starting to build a brand new taxi-hailing application intended to compete with Uber and Hailo. After some preliminary meetings and requirements gathering, you would create a new project either manually or by using a generator that comes with Rails, Spring Boot, Play, or Maven. This new application would have a modular hexagonal architecture, like in the following diagram:

Graph-01

At the core of the application is the business logic, which is implemented by modules that define services, domain objects, and events. Surrounding the core are adapters that interface with the external world. Examples of adapters include database access components, messaging components that produce and consume messages, and web components that either expose APIs or implement a UI.

已有 1 人翻译此段
我来翻译

Despite having a logically modular architecture, the application is packaged and deployed as a monolith. The actual format depends on the application’s language and framework. For example, many Java applications are packaged as WAR files and deployed on application servers such as Tomcat or Jetty. Other Java applications are packaged as self-contained executable JARs. Similarly, Rails and Node.js applications are packaged as a directory hierarchy.

Applications written in this style are extremely common. They are simple to develop since our IDEs and other tools are focused on building a single application. These kinds of applications are also simple to test. You can implement end-to-end testing by simply launching the application and testing the UI with Selenium. Monolithic applications are also simple to deploy. You just have to copy the packaged application to a server. You can also scale the application by running multiple copies behind a load balancer. In the early stages of the project it works well.

已有 1 人翻译此段
我来翻译

Marching Towards Monolithic Hell

Unfortunately, this simple approach has a huge limitation. Successful applications have a habit of growing over time and eventually becoming huge. During each sprint, your development team implements a few more stories, which, of course, means adding many lines of code. After a few years, your small, simple application will have grown into a monstrous monolith. To give an extreme example, I recently spoke to a developer who was writing a tool to analyze the dependencies between the thousands of JARs in their multi-million line of code (LOC) application. I’m sure it took the concerted effort of a large number of developers over many years to create such a beast.

Once your application has become a large, complex monolith, your development organization is probably in a world of pain. Any attempts at agile development and delivery will flounder. One major problem is that the application is overwhelmingly complex. It’s simply too large for any single developer to fully understand. As a result, fixing bugs and implementing new features correctly becomes difficult and time consuming. What’s more, this tends to be a downwards spiral. If the codebase is difficult to understand, then changes won’t be made correctly. You will end up with a monstrous, incomprehensible big ball of mud.

已有 1 人翻译此段
我来翻译

The sheer size of the application will also slow down development. The larger the application, the longer the start-up time is. For example, in a recent survey some developers reported start-up times as long as 12 minutes. I’ve also heard anecdotes of applications taking as long as 40 minutes to start up. If developers regularly have to restart the application server, then a large part of their day will be spent waiting around and their productivity will suffer.

Another problem with a large, complex monolithic application is that it is an obstacle to continuous deployment. Today, the state of the art for SaaS applications is to push changes into production many times a day. This is extremely difficult to do with a complex monolith since you must redeploy the entire application in order to update any one part of it. The lengthy start-up times that I mentioned earlier won’t help either. Also, since the impact of a change is usually not very well understood, it is likely that you have to do extensive manual testing. Consequently, continuous deployment is next to impossible to do.

已有 1 人翻译此段
我来翻译

Monolithic applications can also be difficult to scale when different modules have conflicting resource requirements. For example, one module might implement CPU-intensive image processing logic and would ideally be deployed in AWS EC2 Compute Optimized instances. Another module might be an in-memory database and best suited for EC2 Memory-optimized instances. However, because these modules are deployed together you have to compromise on the choice of hardware.

Another problem with monolithic applications is reliability. Because all modules are running within the same process, a bug in any module, such as a memory leak, can potentially bring down the entire process. Moreover, since all instances of the application are identical, that bug will impact the availability of the entire application.

Last but not least, monolithic applications make it extremely difficult to adopt new frameworks and languages. For example, let’s imagine that you have 2 million lines of code written using the XYZ framework. It would be extremely expensive (in both time and cost) to rewrite the entire application to use the newer ABC framework, even if that framework was considerably better. As a result, there is a huge barrier to adopting new technologies. You are stuck with whatever technology choices you made at the start of the project.

已有 1 人翻译此段
我来翻译

To summarize: you have a successful business-critical application that has grown into a monstrous monolith that very few, if any, developers understand. It is written using obsolete, unproductive technology that makes hiring talented developers difficult. The application is difficult to scale and is unreliable. As a result, agile development and delivery of applications is impossible.

So what can you do about it?

Microservices – Tackling the Complexity

Many organizations, such as Amazon, eBay, and Netflix, have solved this problem by adopting what is now known as the Microservice architecture pattern. Instead of building a single monstrous, monolithic application, the idea is to split your application into set of smaller, interconnected services.

已有 1 人翻译此段
我来翻译

A service typically implements a set of distinct features or functionality, such as order management, customer management, etc. Each microservice is a mini-application that has its own hexagonal architecture consisting of business logic along with various adapters. Some microservices would expose an API that’s consumed by other microservices or by the application’s clients. Other microservices might implement a web UI. At runtime, each instance is often a cloud VM or a Docker container.

For example, a possible decomposition of the system described earlier is shown in the following diagram:

Graph-03

Each functional area of the application is now implemented by its own microservice. Moreover, the web application is split into a set of simpler web applications (such as one for passengers and one for drivers in our taxi-hailing example). This makes it easier to deploy distinct experiences for specific users, devices, or specialized use cases.

已有 1 人翻译此段
我来翻译

Each back-end service exposes a REST API and most services consume APIs provided by other services. For example, Driver Management uses the Notification server to tell an available driver about a potential trip. The UI services invoke the other services in order to render web pages. Services might also use asynchronous, message-based communication. Inter-service communication will be covered in more detail later in this series.

Some REST APIs are also exposed to the mobile apps used by the drivers and passengers. The apps don’t, however, have direct access to the back-end services. Instead, communication is mediated by an intermediary known as an API Gateway. The API Gateway is responsible for tasks such as load balancing, caching, access control, API metering, and monitoring, and can be implemented effectively using NGINX. Later articles in the series will cover the API Gateway.

Graph-05

已有 1 人翻译此段
我来翻译

The Microservice architecture pattern corresponds to the Y-axis scaling of the Scale Cube, which is a 3D model of scalability from the excellent book The Art of Scalability. The other two scaling axes are X-axis scaling, which consists of running multiple identical copies of the application behind a load balancer, and Z-axis scaling (or data partitioning), where an attribute of the request (for example, the primary key of a row or identity of a customer) is used to route the request to a particular server.

Applications typically use the three types of scaling together. Y-axis scaling decomposes the application into microservices as shown above in the first figure in this section. At runtime, X-axis scaling runs multiple instances of each service behind a load balancer for throughput and availability. Some applications might also use Z-axis scaling to partition the services. The following diagram shows how the Trip Management service might be deployed with Docker running on AWS EC2.

Graph-02

已有 1 人翻译此段
我来翻译
本文中的所有译文仅用于学习和交流目的,转载请务必注明文章译者、出处、和本文链接。
我们的翻译工作遵照 CC 协议,如果我们的工作有侵犯到您的权益,请及时联系我们。
加载中

评论(32)

qwfys
qwfys
+1
飞天0407
飞天0407
翻译的真不错,看完基本就可以了解了微服务是干嘛的了已经为什么需要微服务
regulusun
regulusun

引用来自“BaiYang”的评论

这不就是 SOA 么?又起了个叫微服务的小名?

引用来自“0Scn”的评论

94! 只不过比起有些所谓的SOA架构来说粒度更小些罢了。何况SOA本身就没有真正意义的公认的权威的标准定义,某所谓的SOA标准组织给的定义也是极为抽象的。说白了就是为迎合现实的快速发展而带来的更高的互联互通以及灵活性的需求,通过遵循标准化封装、松耦合可编排、复用这三个要点来设计实现。至于落地如何具体设计实现,那本就是依实际应用场景不同而见仁见智的东西。IT行业确实是术语和缩写流行泛滥的行业之一,为了不落人后,某个时段大家总是要争先恐后地跟进的。好吧,为业内方便沟通,为科技进步引领趋势……不管术语和缩写怎么滴好,但总不可避免鱼目混珠,泥沙俱下而导致很多人被混绕视听的。你看,我们老祖宗搞的“统一文字+活字印刷”就很SOA很微服务嘛,N年前我们都如此高大尚了,有木有!
完全同意,微服务即SOA-
andot
andot

引用来自“innerp”的评论

其实 我很好奇 服务直接为什么一定要用rest api ,用rpc性能是不是更好勒
你说的对,RPC 可以提供更好的微服务。Hprose 就是一个很好的微服务 RPC,支持众多语言(支持常用的20多种语言),而且支持众多底层协议(如 HTTP、TCP、WebSocket 等)。没有传统 RPC 的缺点,而且比 REST API 更加轻量级,更加快速,更加易用。
1年1万倍
1年1万倍
我正在路上
单车架构师
单车架构师
在我看来只是换个概念而已,还是逃分布式系统的圈子!
0Scn
0Scn

引用来自“BaiYang”的评论

这不就是 SOA 么?又起了个叫微服务的小名?
94! 只不过比起有些所谓的SOA架构来说粒度更小些罢了。何况SOA本身就没有真正意义的公认的权威的标准定义,某所谓的SOA标准组织给的定义也是极为抽象的。说白了就是为迎合现实的快速发展而带来的更高的互联互通以及灵活性的需求,通过遵循标准化封装、松耦合可编排、复用这三个要点来设计实现。至于落地如何具体设计实现,那本就是依实际应用场景不同而见仁见智的东西。IT行业确实是术语和缩写流行泛滥的行业之一,为了不落人后,某个时段大家总是要争先恐后地跟进的。好吧,为业内方便沟通,为科技进步引领趋势……不管术语和缩写怎么滴好,但总不可避免鱼目混珠,泥沙俱下而导致很多人被混绕视听的。你看,我们老祖宗搞的“统一文字+活字印刷”就很SOA很微服务嘛,N年前我们都如此高大尚了,有木有!
BaiYang
BaiYang
这不就是 SOA 么?又起了个叫微服务的小名?
大胖森
大胖森
微服务实战(一):微服务架构的优势与不足 【编者的话】本文来自Nginx官方博客,是微服务系列文章的第一篇,主要探讨了传统的单体式应用的不足,以及微服务架构的优势与挑战。正如作者所说,微服务架构更适合用于构建复杂的应用,尽管它也有自己的不足。
小鸽子咕噜
小鸽子咕噜
还不错 部分翻译生硬
返回顶部
顶部