从InfoQ上免费下载了一本Microservices for Java Developers，这两天把前面部分稍微过了一下，感觉写的挺明白的。

Microservice的定义
Microservice architecture (MSA) is an approach to building software
systems that decomposes business domain models into smaller,
consistent, bounded-contexts implemented by services. These services
are isolated and autonomous yet communicate to provide some
piece of business functionality. Microservices are typically implemented
and operated by small teams with enough autonomy that
each team and service can change its internal implementation
details (including replacing it outright!) with minimal impact across
the rest of the system.

Microservice的特点
Teams communicate through promises, which are a way a service
can publish intentions to other components or systems that may
wish to use the service. They specify these promises with interfaces
of their services and via wikis that document their services. If there
isn’t enough documentation, or the API isn’t clear enough, the service
provider hasn’t done his job. A little more on promises and
promise theory in the next section.

Each team would be responsible for designing the service, picking
the right technology for the problem set, and deploying, managing
and waking up at 2 a.m. for any issues. For example, at Amazon,
there is a single team that owns the tax-calculation functionality that
gets called during checkout. The models within this service (Item,
Address, Tax, etc.) are all understood to mean “within the context of
calculating taxes” for a checkout; there is no confusion about these
objects (e.g., is the item a return item or a checkout item?). The
team that owns the tax-calculation service designs, develops, and
operates this service. Amazon has the luxury of a mature set of selfservice
tools to automate a lot of the build/deploy/operate steps, but
we’ll come back to that.

Microservice解决的问题
With microservices, we can scope the boundaries of a service, which
helps us:

Understand what the service is doing without being tangled into

other concerns in a larger application

Quickly build the service locally
Pick the right technology for the problem (lots of writes? lots of

queries? low latency? bursty?)

Test the service
Build/deploy/release at a cadence necessary for the business,

which may be independent of other services

Identify and horizontally scale parts of the architecture where

needed

Improve resiliency of the system as a whole

Microservices help solve the “how do we decouple our services and
teams to move quickly at scale?” problem. It allows teams to focus
on providing the service and making changes when necessary and
to do so without costly synchronization points. Here are things you
won’t hear once you’ve adopted microservices:

Jira tickets
Unnecessary meetings
Shared libraries
Enterprise-wide canonical models

Microservice是否适合你? （Microsercie带来很多好处，不过也都是有代价的）
Is microservice architecture right for you? Microservices have a lot
of benefits, but they come with their own set of drawbacks. You can
think of microservices as an optimization for problems that require
the ability to change things quickly at scale but with a price. It’s not

1. It can be more resource intensive. You may end up with
2. looks like duplication. Operational complexity is a lot higher. It

becomes very difficult to understand the system holistically. It
becomes significantly harder to debug problems. In some areas you
may have to relax the notion of transaction. Teams may not have
been designed to work like this.

并不是所有的业务都适合Microservice
Not every part of the business has to be able to change on a dime. A
lot of customer-facing applications do. Backend systems may not.
But as those two worlds start to blend together we may see the forces
that justify microservice architectures push to other parts of the system.

书不长一百多页，后面具体的配置、编码的部分还没看，前面看了感觉写的还可以。有需要的可以去InfoQ下载。
https://www.infoq.com/vendorcontent/show.action?vcr=4339&utm_source=infoq&utm_medium=VCR&utm_campaign=vcr_homePage_click&utm_content=bottom