NET-Microservices-Architecture-for-Containerized-NET-Applications-(Microsoft-eBook)

More documents

Recommendations

Info

these calls increases significantly and at the same time one of the intermediate HTTP calls to a microservice is blocked. The result is that performance is impacted, and the overall scalability will be exponentially affected as additional HTTP requests increase. • Coupling microservices with HTTP. Business microservices should not be coupled with other business microservices. Ideally, they should not “know” about the existence of other microservices. If your application relies on coupling microservices as in the example, achieving autonomy per microservice will be almost impossible. • Failure in any one microservice. If you implemented a chain of microservices linked by HTTP calls, when any of the microservices fails (and eventually they will fail) the whole chain of microservices will fail. A microservice-based system should be designed to continue to work as well as possible during partial failures. Even if you implement client logic that uses retries with exponential backoff or circuit breaker mechanisms, the more complex the HTTP call chains are, the more complex it is implement a failure strategy based on HTTP. In fact, if your internal microservices are communicating by creating chains of HTTP requests as described, it could be argued that you have a monolithic application, but one based on HTTP between processes instead of intraprocess communication mechanisms. Therefore, in order to enforce microservice autonomy and have better resiliency, you should minimize the use of chains of request/response communication across microservices. It is recommended that you use only asynchronous interaction for inter-microservice communication, either by using asynchronous message- and event-based communication, or by using (asynchronous) HTTP polling independently of the original HTTP request/response cycle. The use of asynchronous communication is explained with additional details later in this guide in the sections Asynchronous microservice integration enforces microservice’s autonomy and Asynchronous message-based communication. Additional resources • CAP theorem https://en.wikipedia.org/wiki/CAP_theorem • Eventual consistency https://en.wikipedia.org/wiki/Eventual_consistency • Data Consistency Primer https://msdn.microsoft.com/library/dn589800.aspx • Martin Fowler. CQRS (Command and Query Responsibility Segregation) http://martinfowler.com/bliki/CQRS.html • Materialized View https://docs.microsoft.com/azure/architecture/patterns/materialized-view • Charles Row. ACID vs. BASE: The Shifting pH of Database Transaction Processing http://www.dataversity.net/acid-vs-base-the-shifting-ph-of-database-transaction-processing/ • Compensating Transaction https://docs.microsoft.com/azure/architecture/patterns/compensating-transaction • Udi Dahan. Service Oriented Composition http://udidahan.com/2014/07/30/service-oriented-composition-with-video/ 36 Architecting Container- and Microservice-Based Applications
Identify domain-model boundaries for each microservice The goal when identifying model boundaries and size for each microservice is not to get to the most granular separation possible, although you should tend toward small microservices if possible. Instead, your goal should be to get to the most meaningful separation guided by your domain knowledge. The emphasis is not on the size, but instead on business capabilities. In addition, if there is clear cohesion needed for a certain area of the application based on a high number of dependencies, that indicates the need for a single microservice, too. Cohesion is a way to identify how to break apart or group together microservices. Ultimately, while you gain more knowledge about the domain, you should adapt the size of your microservice, iteratively. Finding the right size is not a one-shot process. Sam Newman, a recognized promoter of microservices and author of the book Building Microservices, highlights that you should design your microservices based on the Bounded Context (BC) pattern (part of domain-driven design), as introduced earlier. Sometimes, a BC could be composed of several physical services, but not vice versa. A domain model with specific domain entities applies within a concrete BC or microservice. A BC delimits the applicability of a domain model and gives developer team members a clear and shared understanding of what must be cohesive and what can be developed independently. These are the same goals for microservices. Another tool that informs your design choice is Conway’s law, which states that an application will reflect the social boundaries of the organization that produced it. But sometimes the opposite is true—the company’s organization is formed by the software. You might need to reverse Conway’s law and build the boundaries the way you want the company to be organized, leaning toward business process consulting. In order to identify bounded contexts, a DDD pattern that can be used for this is the Context Mapping pattern. With Context Mapping, you identify the various contexts in the application and their boundaries. It is common to have a different context and boundary for each small subsystem, for instance. The Context Map is a way to define and make explicit those boundaries between domains. A BC is autonomous and includes the details of a single domain—details like the domain entities—and defines integration contracts with other BCs. This is similar to the definition of a microservice: it is autonomous, it implements certain domain capability, and it must provide interfaces. This is why Context Mapping and the Bounded Context pattern are good approaches for identifying the domain model boundaries of your microservices. When designing a large application, you will see how its domain model can be fragmented — a domain expert from the catalog domain will name entities differently in the catalog and inventory domains than a shipping domain expert, for instance. Or the user domain entity might be different in size and number of attributes when dealing with a CRM expert who wants to store every detail about the customer than for an ordering domain expert who just needs partial data about the customer. It is very hard to disambiguate all domain terms across all the domains related to a large application. But the most important thing is that you should not try to unify the terms; instead, accept the differences and richness provided by each domain. If you try to have a unified database for the whole application, attempts at a unified vocabulary will be awkward and will not sound right to any of the multiple domain experts. Therefore, BCs (implemented as microservices) will help you to clarify where you can use certain domain terms and where you will need to split the system and create additional BCs with different domains. 37 Architecting Container- and Microservice-Based Applications
Page 1 and 2: i
Page 3 and 4: Contents Introduction .............
Page 5 and 6: Designing a microservice-oriented a
Page 7 and 8: Table mapping .....................
Page 9 and 10: S E C T I O N 1 Introduction Enterp
Page 11 and 12: Send us your feedback! We wrote thi
Page 13 and 14: In short, containers offer the bene
Page 15 and 16: The main goal of an image is that i
Page 17 and 18: Docker containers, images, and regi
Page 19 and 20: • You need to use third-party .NE
Page 21 and 22: When to choose .NET Framework for D
Page 23 and 24: Decision table: .NET frameworks to
Page 25 and 26: microsoft/dotnet:2.1-aspnetcorerunt
Page 27 and 28: S E C T I O N 4 Architecting Contai
Page 29 and 30: For example, in a typical e-commerc
Page 31 and 32: Figure 4-4. Publishing a single-con
Page 33 and 34: As shown in Figure 4-5, regular Doc
Page 35 and 36: Microservices architecture As the n
Page 37 and 38: Data sovereignty per microservice A
Page 39 and 40: It is important to highlight that d
Page 41 and 42: Challenge #2: How to create queries
Page 43: The Catalog microservice should not
Page 47 and 48: Figure 4-11. Decomposing traditiona
Page 49 and 50: example, when handling dozens of mi
Page 51 and 52: Figure 4-13. Using an API Gateway i
Page 53 and 54: microservices. With this approach,
Page 55 and 56: deployment environment where you ar
Page 57 and 58: • Asynchronous protocol. Other pr
Page 59 and 60: If your microservice needs to raise
Page 61 and 62: Figure 4-17. One-to-one real-time a
Page 63 and 64: Figure 4-18. A single microservice
Page 65 and 66: A note about messaging technologies
Page 67 and 68: Microservices addressability and th
Page 69 and 70: Figure 4-21. Example of a composite
Page 71 and 72: microservice to recover. Health eve
Page 73 and 74: Orchestrating microservices and mul
Page 75 and 76: DC/OS works by abstracting a collec
Page 77 and 78: might choose to use the Docker comm
Page 79 and 80: called a Gateway service if you imp
Page 81 and 82: Figure 4-30. Stateless versus state
Page 83 and 84: .NET languages and frameworks for D
Page 85 and 86: Set up your local environment with
Page 87 and 88: use is microsoft/aspnetcore:2.0. Th
Page 89 and 90: Step 3. Create your custom Docker i
Page 91 and 92: Note that this docker-compose.yml f
Page 93 and 94: Figure 5-10. VM with Docker contain
Page 95 and 96:
Note that this URL in the browser u
Page 97 and 98:
Using PowerShell commands in a Dock
Page 99 and 100:
The application will consist of the
Page 101 and 102:
Communication architecture. The eSh
Page 103 and 104:
client and the APIs exposed by each
Page 105 and 106:
The new world: multiple architectur
Page 107 and 108:
Figure 6-5. Simple data-driven/CRUD
Page 109 and 110:
The data model With EF Core, data a
Page 111 and 112:
itemsOnPage = ChangeUriPlaceholder(
Page 113 and 114:
- ConnectionString=Server=sql.data;
Page 115 and 116:
• tool can be used from the CLI a
Page 117 and 118:
} options.SwaggerDoc("v1", new Swas
Page 119 and 120:
Defining your multi-container appli
Page 121 and 122:
The root key in this file is servic
Page 123 and 124:
Development environments When you d
Page 125 and 126:
eShopOnContainers has the following
Page 127 and 128:
#docker-compose.override.yml (Exten
Page 129 and 130:
In this example, the development ov
Page 131 and 132:
Building the application from a bui
Page 133 and 134:
Creating the Docker images from the
Page 135 and 136:
When you start this SQL Server cont
Page 137 and 138:
EF Core InMemory database versus SQ
Page 139 and 140:
Implementing event-based communicat
Page 141 and 142:
multiple microservices; doing that
Page 143 and 144:
void SubscribeDynamic(string eventN
Page 145 and 146:
Implementing the subscription code
Page 147 and 148:
[Route("update")] [HttpPost] public
Page 149 and 150:
your domain entities. That table wo
Page 151 and 152:
Update Product from the Catalog mic
Page 153 and 154:
private async Task UpdatePriceInBas
Page 155 and 156:
Deduplicating integration event mes
Page 157 and 158:
Testing ASP.NET Core services and w
Page 159 and 160:
public class PrimeWebDefaultRequest
Page 161 and 162:
Therefore, you can choose and eithe
Page 163 and 164:
Copyright (c) .NET Foundation. Lice
Page 165 and 166:
By default, the cancellation token
Page 167 and 168:
Going much further in the design, s
Page 169 and 170:
In regards the microservice URL, wh
Page 171 and 172:
Implementing your API Gateways with
Page 173 and 174:
} "UpstreamHttpMethod": [ "POST", "
Page 175 and 176:
created from that same Docker image
Page 177 and 178:
Because of testing or debugging rea
Page 179 and 180:
Figure 6-38. Position of the Identi
Page 181 and 182:
… Then, you also need to set auth
Page 183 and 184:
The deployment of eShopOnContainers
Page 185 and 186:
However, most of the techniques for
Page 187 and 188:
Figure 7-2. Simplified CQRS- and DD
Page 189 and 190:
• Udi Dahan. Clarified CQRS http:
Page 191 and 192:
You will also need to add a using s
Page 193 and 194:
Describing Response Types of Web AP
Page 195 and 196:
Designing a DDD-oriented microservi
Page 197 and 198:
Figure 7-6. Layers implemented as l
Page 199 and 200:
Figure 7-7. Dependencies between la
Page 201 and 202:
Figure 7-8. Example of a domain ent
Page 203 and 204:
• Eric Evans. Domain-Driven Desig
Page 205 and 206:
Additional resources • Vaughn Ver
Page 207 and 208:
layer library, so the domain model
Page 209 and 210:
In addition, the class is decorated
Page 211 and 212:
Mapping properties with only get ac
Page 213 and 214:
} } protected set { _Id = value; }
Page 215 and 216:
Repository contracts (interfaces) i
Page 217 and 218:
constructed, you must provide the r
Page 219 and 220:
How to persist value objects in the
Page 221 and 222:
} In the previous code, the orderCo
Page 223 and 224:
• Complex types and/or value obje
Page 225 and 226:
public override bool Equals(object
Page 227 and 228:
A better example would demonstrate
Page 229 and 230:
Just as the view model and the doma
Page 231 and 232:
external applications. Hence, they
Page 233 and 234:
Figure 7-15. Handling multiple acti
Page 235 and 236:
However, when the domain events cla
Page 237 and 238:
Any rule that spans Aggregates will
Page 239 and 240:
You can build all the plumbing and
Page 241 and 242:
Domain events can generate integrat
Page 243 and 244:
We must emphasize again that only o
Page 245 and 246:
These multiple persistence operatio
Page 247 and 248:
Implementing the infrastructure per
Page 249 and 250:
At OrderingContext.cs from eShopOnC
Page 251 and 252:
Methods to implement in a repositor
Page 253 and 254:
public IServiceProvider ConfigureSe
Page 255 and 256:
At OrderingContext.cs from eShopOnC
Page 257 and 258:
Implementing the Specification patt
Page 259 and 260:
Additional resources • Table Mapp
Page 261 and 262:
{ } "id": "2017001", "orderDate": "
Page 263 and 264:
Implementing .NET code targeting Mo
Page 265 and 266:
Analyze your approach for productio
Page 267 and 268:
Retrieve the database and the colle
Page 269 and 270:
Designing the microservice applicat
Page 271 and 272:
Sample command handler public class
Page 273 and 274:
Using Autofac as an IoC container Y
Page 275 and 276:
The command class A command is a re
Page 277 and 278:
} CardNumber = cardNumber; CardHold
Page 279 and 280:
public class CreateOrderCommandHand
Page 281 and 282:
mediator pipeline (see Mediator pat
Page 283 and 284:
Implementing the command process pi
Page 285 and 286:
command won’t be processed again,
Page 287 and 288:
Registering the types used by Media
Page 289 and 290:
The eShopOnContainers ordering micr
Page 291 and 292:
• Put your controllers on a diet:
Page 293 and 294:
eventually the application’s runt
Page 295 and 296:
Use retries with exponential backof
Page 297 and 298:
transaction when using an EF execut
Page 299 and 300:
public ExponentialBackoff(int maxRe
Page 301 and 302:
• Use HttpClientFactory Directly
Page 303 and 304:
{ } _httpClient = httpClient; publi
Page 305 and 306:
With Polly, you can define a Retry
Page 307 and 308:
Testing the circuit breaker in eSho
Page 309 and 310:
Adding a jitter strategy to the ret
Page 311 and 312:
does not have any dependency on Azu
Page 313 and 314:
namespace Microsoft.eShopOnContaine
Page 315 and 316:
Health checks when using orchestrat
Page 317 and 318:
Figure 9-2. Authentication by ident
Page 319 and 320:
Sign in the user with this external
Page 321 and 322:
Configure the OWIN pipeline to use
Page 323 and 324:
Additional resources • Sharing co
Page 325 and 326:
In this example, only users in the
Page 327 and 328:
Storing application secrets safely
Page 329 and 330:
Configure Key Vault client var kvCl
Page 331:
CLI versus IDE. With Microsoft tool
show all

NET-Microservices-Architecture-for-Containerized-NET-Applications-(Microsoft-eBook)

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?