优化微服务：NGINX实战与应用

1星需积分: 10 187 浏览量更新于2024-07-20 收藏 3.34MB PDF 举报

《构建微服务：Nginx篇》是一本由Sam Newman撰写的专业书籍，专注于介绍如何利用Nginx这一强大的Web服务器和应用交付平台在构建微服务架构时实现性能优化和高效运作。Nginx作为全球最受欢迎的服务器软件之一，被超过13亿网站所信赖，支撑着全球三分之一最繁忙的互联网流量。书中提到的重要知识点包括： 1. **负载均衡**：Nginx作为一个高效的负载均衡器，能够优化应用程序、APIs和服务的可用性。它通过将请求分发到多个后端服务器，确保在高流量下也能维持稳定的响应速度，并通过自动探测和轮询策略来适应服务器的动态变化。 2. **Web服务器功能**：Nginx不仅局限于负载均衡，它还是一个功能全面的Web服务器，可以处理静态内容，如HTML、CSS和JavaScript，从而减少后端压力，提高网站性能。 3. **内容缓存**：Nginx支持内容缓存，通过存储重复请求的响应结果，加快了访问速度，减少了网络延迟，特别是在处理大量用户同时访问时。 4. **边缘计算与加速**：Nginx允许开发者创建边缘服务器，直接将视频等高质内容推送到用户设备，无需经过中央服务器，显著提升了用户体验。 5. **流媒体处理**：Nginx在流媒体服务方面表现出色，能实时、高质量地向任何设备提供视频服务，这对于视频点播和实时通信应用至关重要。 6. **完整应用交付平台**：Nginx Plus作为增强版，提供了完整的应用交付平台，整合了负载均衡、Web服务器和高级功能，帮助企业构建和管理复杂的微服务架构。《构建微服务》这本书是作者Sam Newman的作品，预计于2015年2月发布，届时可在O'Reilly官网和其他零售商处购买。这本书包含三个章节（第1章、第4章和第11章），是关于微服务构建的深入指南，适合希望优化微服务架构的开发人员和IT专业人员参考。版权所有，未经许可不得复制或传播。

Figure 1-2. You can target scaling at just those microservices that need it

Gilt, an online fashion retailer, adopted microservices for this exact reason. Starting

in 2007 with a monolithic Rails application, by 2009 Gilt’s system was unable to cope

with the load being placed on it. By splitting out core parts of its system, Gilt was bet‐

ter able to deal with its traffic spikes, and today has over 450 microservices, each one

running on multiple separate machines.

When embracing on-demand provisioning systems like those provided by Amazon

Web Services, we can even apply this scaling on demand for those pieces that need it.

This allows us to control our costs more effectively. It’s not often that an architectural

approach can be so closely correlated to an almost immediate cost savings.

Ease of Deployment

A one-line change to a million-line-long monolithic application requires the whole

application to be deployed in order to release the change. That could be a large-

impact, high-risk deployment. In practice, large-impact, high-risk deployments end

up happening infrequently due to understandable fear. Unfortunately, this means that

our changes build up and build up between releases, until the new version of our

application hitting production has masses of changes. And the bigger the delta

between releases, the higher the risk that we’ll get something wrong!

With microservices, we can make a change to a single service and deploy it independ‐

ently of the rest of the system. This allows us to get our code deployed faster. If a

problem does occur, it can be isolated quickly to an individual service, making fast

rollback easy to achieve. It also means we can get our new functionality out to cus‐

tomers faster. This is one of the main reasons why organizations like Amazon and

Netflix use these architectures—to ensure they remove as many impediments as pos‐

sible to getting software out the door.

6 | Chapter 1: Microservices

The technology in this space has changed greatly in the last couple of years, and we’ll

be looking more deeply into the topic of deployment in a microservice world in

(cross-ref to come).

Organizational Alignment

Many of us have experienced the problems associated with large teams and large

codebases. These problems can be exacerbated when the team is distributed. We also

know that smaller teams working on smaller codebases tend to be more productive.

Microservices allow us to better align our architecture to our organization, helping us

minimize the number of people working on any one codebase to hit the sweet spot of

team size and productivity. We can also shift ownership of services between teams to

try to keep people working on one service colocated. We will go into much more

detail on this topic when we discuss Conway’s law in (cross-ref to come).

Composability

One of the key promises of distributed systems and service-oriented architectures is

that we open up opportunities for reuse of functionality. With microservices, we

allow for our functionality to be consumed in different ways for different purposes.

This can be especially important when we think about how our consumers use our

software. Gone is the time when we could think narrowly about either our desktop

website or mobile application. Now we need to think of the myriad ways that we

might want to weave together capabilities for the Web, native application, mobile web,

tablet app, or wearable device. As organizations move away from thinking in terms of

narrow channels to more holistic concepts of customer engagement, we need archi‐

tectures that can keep up.

With microservices, think of us opening up seams in our system that are addressable

by outside parties. As circumstances change, we can build things in different ways.

With a monolithic application, I often have one coarse-grained seam that can be used

from the outside. If I want to break that up to get something more useful, I’ll need a

hammer! In (cross-ref to come), I’ll discuss ways for you to break apart existing mon‐

olithic systems, and hopefully change them into some reusable, re-composable

microservices.

Optimizing for Replaceability

If you work at a medium-size or bigger organization, chances are you are aware of

some big, nasty legacy system sitting in the corner. The one no one wants to touch.

The one that is vital to how your company runs, but that happens to be written in

some odd Fortran variant and runs only on hardware that reached end of life 25 years

ago. Why hasn’t it been replaced? You know why: it’s too big and risky a job.

Key Benets | 7

With our individual services being small in size, the cost to replace them with a better

implementation, or even delete them altogether, is much easier to manage. How often

have you deleted more than a hundred lines of code in a single day and not worried

too much about it? With microservices often being of similar size, the barriers to

rewriting or removing services entirely are very low.

Teams using microservice approaches are comfortable with completely rewriting

services when required, and just killing a service when it is no longer needed. When a

codebase is just a few hundred lines long, it is difficult for people to become emotion‐

ally attached to it, and the cost of replacing it is pretty small.

What About Service-Oriented Architecture?

Service-oriented architecture (SOA) is a design approach where multiple services col‐

laborate to provide some end set of capabilities. A service here typically means a com‐

pletely separate operating system process. Communication between these services

occurs via calls across a network rather than method calls within a process boundary.

SOA emerged as an approach to combat the challenges of the large monolithic appli‐

cations. It is an approach that aims to promote the reusability of software; two or

more end-user applications, for example, could both use the same services. It aims to

make it easier to maintain or rewrite software, as theoretically we can replace one ser‐

vice with another without anyone knowing, as long as the semantics of the service

don’t change too much.

SOA at its heart is a very sensible idea. However, despite many efforts, there is a lack

of good consensus on how to do SOA well. In my opinion, much of the industry has

failed to look holistically enough at the problem and present a compelling alternative

to the narrative set out by various vendors in this space.

Many of the problems laid at the door of SOA are actually problems with things like

communication protocols (e.g., SOAP), vendor middleware, a lack of guidance about

service granularity, or the wrong guidance on picking places to split your system.

We’ll tackle each of these in turn throughout the rest of the book. A cynic might sug‐

gest that vendors co-opted (and in some cases drove) the SOA movement as a way to

sell more products, and those selfsame products in the end undermined the goal of

SOA.

Much of the conventional wisdom around SOA doesn’t help you understand how to

split something big into something small. It doesn’t talk about how big is too big. It

doesn’t talk enough about real-world, practical ways to ensure that services do not

become overly coupled. The number of things that go unsaid is where many of the

pitfalls associated with SOA originate.

8 | Chapter 1: Microservices

The microservice approach has emerged from real-world use, taking our better

understanding of systems and architecture to do SOA well. So you should instead

think of microservices as a specific approach for SOA in the same way that XP or

Scrum are specific approaches for Agile software development.

Other Decompositional Techniques

When you get down to it, many of the advantages of a microservice-based architec‐

ture come from its granular nature and the fact that it gives you many more choices

as to how to solve problems. But could similar decompositional techniques achieve

the same benefits?

Shared Libraries

A very standard decompositional technique that is built into virtually any language is

breaking down a codebase into multiple libraries. These libraries may be provided by

third parties, or created in your own organization.

Libraries give you a way to share functionality between teams and services. I might

create a set of useful collection utilities, for example, or perhaps a statistics library

that can be reused.

Teams can organize themselves around these libraries, and the libraries themselves

can be reused. But there are some drawbacks.

First, you lose true technology heterogeneity. The library typically has to be in the

same language, or at the very least run on the same platform. Second, the ease with

which you can scale parts of your system independently from each other is curtailed.

Next, unless you’re using dynamically linked libraries, you cannot deploy a new

library without redeploying the entire process, so your ability to deploy changes in

isolation is reduced. And perhaps the kicker is that you lack the obvious seams

around which to erect architectural safety measures to ensure system resiliency.

Shared libraries do have their place. You’ll find yourself creating code for common

tasks that aren’t specific to your business domain that you want to reuse across the

organization, which is an obvious candidate for becoming a reusable library. You do

need to be careful, though. Shared code used to communicate between services can

become a point of coupling, something we’ll discuss in Chapter 2.

Services can and should make heavy use of third-party libraries to reuse common

code. But they don’t get us all the way there.

Other Decompositional Techniques | 9

Modules

Some languages provide their own modular decomposition techniques that go

beyond simple libraries. They allow some lifecycle management of the modules, such

that they can be deployed into a running process, allowing you to make changes

without taking the whole process down.

The Open Source Gateway Initiative (OSGI) is worth calling out as one technology-

specific approach to modular decomposition. Java itself doesn’t have a true concept of

modules, and we’ll have to wait at least until Java 9 to see this added to the language.

OSGI, which emerged as a framework to allow plug-ins to be installed in the Eclipse

Java IDE, is now used as a way to retrofit a module concept in Java via a library.

The problem with OSGI is that it is trying to enforce things like module lifecycle

management without enough support in the language itself. This results in more

work having to be done by module authors to deliver on proper module isolation.

Within a process boundary, it is also much easier to fall into the trap of making mod‐

ules overly coupled to each other, causing all sorts of problems. My own experience

with OSGI, which is matched by that of colleagues in the industry, is that even with

good teams it is easy for OSGI to become a much bigger source of complexity than its

benefits warrant.

Erlang follows a different approach, in which modules are baked into the language

runtime. Thus, Erlang is a very mature approach to modular decomposition. Erlang

modules can be stopped, restarted, and upgraded without issue. Erlang even supports

running more than one version of the module at a given time, allowing for more

graceful module upgrading.

The capabilities of Erlang’s modules are impressive indeed, but even if we are lucky

enough to use a platform with these capabilities, we still have the same shortcomings

as we do with normal shared libraries. We are strictly limited in our ability to use new

technologies, limited in how we can scale independently, can drift toward integration

techniques that are overly coupling, and lack seams for architectural safety measures.

There is one final observation worth sharing. Technically, it should be possible to cre‐

ate well-factored, independent modules within a single monolithic process. And yet

we rarely see this happen. The modules themselves soon become tightly coupled with

the rest of the code, surrendering one of their key benefits. Having a process bound‐

ary separation does enforce clean hygiene in this respect (or at least makes it harder

to do the wrong thing!). I wouldn’t suggest that this should be the main driver for

process separation, of course, but it is interesting that the promises of modular sepa‐

ration within process boundaries rarely deliver in the real world.

So while modular decomposition within a process boundary may be something you

want to do as well as decomposing your system into services, by itself it won’t help

10 | Chapter 1: Microservices

剩余101页未读，继续阅读

热血蜗牛

粉丝: 1104
资源: 21

优化微服务：NGINX实战与应用

nginx流媒体安装包(nginx_mod_h264_streaming,yamdi)

nginx.config_nginx_

Oldish_Microservices：具有可扩展但昂贵的体系结构的Oldish

nginx-1.16.1_nginx1.16_nginx1.16.1https_111111_nginx1.16.1_nginx

05尚硅谷_Nginx_hit1qr_nginx尚硅谷_nginx_

passenger_nginx_vhost_test:练习和测试passenger_nginx_vhost LWRP的食谱

Linux_Nginx_编译安装_nginx.zip

nginx自己_nginx_

nginx-rtmp-win32.rar_connectedoi2_nginx_nginx-rtmp-win32_withvl3

nginx-1.10.2_海康；javascript_nginx/1.10.2_nginx转发海康_

最新资源