Sync docs from master to gh-pages
This commit is contained in:
buildmaster
@@ -103,11 +103,29 @@ $(addBlockSwitches);
|
||||
<div id="preamble">
|
||||
<div class="sectionbody">
|
||||
<div class="paragraph">
|
||||
<p>Spring Cloud Sleuth implements a distributed tracing solution for Spring Cloud, borrowing
|
||||
heavily from <a href="https://research.google.com/pubs/pub36356.html">Dapper</a>,
|
||||
<a href="https://github.com/openzipkin/zipkin">Zipkin</a>, and HTrace. For most users, Sleuth should be
|
||||
invisible, and all your interactions with external systems should be instrumented
|
||||
automatically. You can capture data in logs or by sending it to a remote collector service.</p>
|
||||
<p>Spring Cloud Contract is an umbrella project holding solutions that help users in successfully implementing the Consumer Driven Contracts approach. Currently Spring Cloud Contract consists of the Spring Cloud Contract Verifier project.</p>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Spring Cloud Contract Verifier is a tool that enables Consumer Driven Contract (CDC) development of JVM-based applications. It is shipped with Contract Definition Language (DSL) written in Groovy or YAML. Contract definitions are used to produce following resources:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>by default JSON stub definitions to be used by WireMock (HTTP Server Stub) when doing integration testing on the client code (client tests). Test code must still be written by hand, test data is produced by Spring Cloud Contract Verifier.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Messaging routes if you’re using one. We’re integrating with Spring Integration, Spring Cloud Stream and Apache Camel. You can however set your own integrations if you want to.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Acceptance tests (by default in JUnit or Spock) used to verify if server-side implementation of the API is compliant with the contract (server tests). Full test is generated by Spring Cloud Contract Verifier.</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Spring Cloud Contract Verifier moves TDD to the level of software architecture.</p>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>To see how Spring Cloud Contract supports other languages just check out this blog post.</p>
|
||||
</div>
|
||||
</div>
|
||||
</div>
|
||||
@@ -115,38 +133,105 @@ automatically. You can capture data in logs or by sending it to a remote collect
|
||||
<h2 id="_features"><a class="link" href="#_features">Features</a></h2>
|
||||
<div class="sectionbody">
|
||||
<div class="paragraph">
|
||||
<p>A span is the basic unit of work. For example, sending an RPC is a new span, as is sending
|
||||
a response to an RPC. Spans are identified by a unique 64-bit ID for the span and another
|
||||
64-bit ID for the trace of which the span is a part. Spans also have other data, such as
|
||||
descriptions, key-value annotations, the ID of the span that caused them, and process IDs
|
||||
(normally IP addresses). Spans are started and stopped, and they keep track of their
|
||||
timing information. Once you create a span, you must stop it at some point in the future.
|
||||
A set of spans (which form a tree-like structure) is called a trace. For example, if you
|
||||
run a distributed big-data store, a trace might be formed by a <code>PUT</code> request.</p>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Spring Cloud Sleuth:</p>
|
||||
<p>When trying to test an application that communicates with other services then we could do one of two things:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>Adds trace and span IDs to the Slf4J MDC so that you can extract all the logs from a
|
||||
given trace or span in a log aggregator.</p>
|
||||
<p>deploy all microservices and perform end to end tests</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Provides an abstraction over common distributed tracing data models: traces, spans
|
||||
(forming a DAG), annotations, and key-value annotations. This is loosely based on HTrace
|
||||
but is Zipkin (Dapper) compatible.</p>
|
||||
<p>mock other microservices in unit / integration tests</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Both have their advantages but also a lot of disadvantages. Let’s focus on the latter.
|
||||
Deploy all microservices and perform end to end tests</p>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Advantages:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>simulates production</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>Instruments common ingress and egress points from Spring applications (servlet filter,
|
||||
rest template, scheduled actions, message channels, zuul filters, and the feign client).</p>
|
||||
<p>tests real communication between services</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Disadvantages:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>to test one microservice we would have to deploy 6 microservices, a couple of databases etc.</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>If <code>spring-cloud-sleuth-zipkin</code> is available, the app generates and collects
|
||||
Zipkin-compatible traces over HTTP. By default, it sends them to a Zipkin collector
|
||||
service on localhost (port 9411). You can configure the location of the service using
|
||||
<code>spring.zipkin.baseUrl</code>.</p>
|
||||
<p>the environment where the tests would be conducted would be locked for a single suite of tests (i.e. nobody else would be able to run the tests in the meantime).</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>long to run</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>very late feedback</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>extremely hard to debug</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Mock other microservices in unit / integration tests</p>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Advantages:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>very fast feedback</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>no infrastructure requirements</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Disadvantages:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>the implementor of the service creates stubs thus they might have nothing to do with the reality</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>you can go to production with passing tests and failing production</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>To solve the aforementioned issues Spring Cloud Contract Verifier with Stub Runner were created. Their main idea is to give you very fast feedback, without the need to set up the whole world of microservices.</p>
|
||||
</div>
|
||||
<div class="paragraph">
|
||||
<p>Spring Cloud Contract Verifier features:</p>
|
||||
</div>
|
||||
<div class="ulist">
|
||||
<ul>
|
||||
<li>
|
||||
<p>ensure that HTTP / Messaging stubs (used when developing the client) are doing exactly what actual server-side implementation will do</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>promote acceptance test driven development method and Microservices architectural style</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>to provide a way to publish changes in contracts that are immediately visible on both sides of the communication</p>
|
||||
</li>
|
||||
<li>
|
||||
<p>to generate boilerplate test code used on the server side</p>
|
||||
</li>
|
||||
</ul>
|
||||
</div>
|
||||
|
||||
Reference in New Issue
Block a user