网络科技

    今日:120| 主题:244924
收藏本版
互联网、科技极客的综合动态。

[其他] Getting Started With Microservices

[复制链接]
此生赐情 发表于 2016-10-17 21:32:07
217 8

立即注册CoLaBug.com会员,免费获得投稿人的专业资料,享用更多功能,玩转个人品牌!

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
Section 1      
    Introduction

      The term “microservices” describes a new software development pattern that has grown from recent trends in software development/management practices meant to increase the speed and efficiency of developing and managing software solutions. Agile methods, DevOps culture, PaaS, application containers, and the widespread adoption (both culturally and technically) of CI/CD methods across the marketplace are making it possible to consider building truly modular large-scale service systems for both internal and commercial use.
            Section 2      
    What Are Microservices?

      Microservices involve an architectural approach that emphasizes the decomposition of applications into single-purpose, loosely coupled services managed by cross-functional teams, for delivering and maintaining complex software systems with the velocity and quality required by today’s digital business.
   Microservices are language-, platform-, and operating system- agnostic. They break down a big monolithic application, typically packaged as a single archive, into smaller and simpler applications. Each application does one thing, and does it well, so the “micro” in microservices refers to the scope of the services’ functionalities, as opposed to the number of Lines of Code (LOC).
   Each application is built by a full-stack team, which reduces potential communication mismatch between different teams that could exist otherwise. Microservices may not be suitable for simpler applications and are better suited for complex applications that have grown over a period of time.
   The availability of an application on a mobile device; the frequency with which an application needs to be updated; and the responsiveness of an application’s design are a few key factors driving this style of architecture.
   The concept behind microservices is similar to Service-oriented Architecture (SOA), which is why this style of architecture has been referred to as “SOA with DevOps,” “SOA for hipsters,” and “SOA 2.0”.
            Section 3      
    Key Characteristics of Microservices

      
       
  • Domain-Driven Design: Functional decomposition can be easily achieved using Eric Evans’s DDD approach.   
  • Single Responsibility Principle: Each service is responsible for a single part of the functionality, and does it well.   
  • Explicitly Published Interface: A producer service publishes an interface that is used by a consumer service.   
  • Independent DURS (Deploy, Update, Replace, Scale): Each service can be independently deployed, updated, replaced, and scaled.   
  • Lightweight Communication: REST over HTTP, STOMP over WebSocket, and other similar lightweight protocols are used for communication between services.   
            Section 4      
    Benefits of Microservices

      
       
  • Independent scaling: Each microservice can scale independently via X-axis scaling (cloning with more CPU or memory) and Z-axis scaling (sharding), based upon their needs. This is very different from monolithic applications, which may have very different requirements that must be deployed together.   
  • Independent upgrades: Each service can be deployed independent of other services. Any change local to a service can be easily made by a developer without requiring coordination with other teams. For example, performance of a service can be improved by changing the underlying implementation. As a result this maintains the agility of the microservice. This is also a great enabler of CI/CD.   
  • Easy maintenance: Code in a microservice is restricted to one function and is thus easier to understand. IDEs can load the smaller amounts of code more easily, and increased readability can keep developers more productive.   
  • Potential heterogeneity and polyglotism: Developers are free to pick the language and stack that are best suited for their service. This enables one to rewrite the service using better languages and technologies as opposed to being penalized because of past decisions, and gives freedom of choice when picking a technology, tool, or framework.   
  • Fault and resource isolation: A misbehaving service, such as a memory leak or an unclosed database connection, will only affect that service, as opposed to an entire monolithic application. This improves fault isolation and limits how much of an application a failure can affect.   
  • Improved communication across teams: A microservice is typically built by a full-stack team. All members related to a domain work together in a single team, which significantly improves communication between team members, as they share the same end goal.   
            Section 5      
    Operational Requirements for Microservices

          Microservices are not the silver bullet that will solve all architectural problems in your applications. Implementing microservices may help, but that is often just the byproduct of refactoring your application and typically rewriting code using guidelines required by this architecture style. True success requires significant investment.
   
         
  • Service Replication: Each service needs to replicate, typically using X-axis cloning or Y-axis partitioning. There should be a standard mechanism by which services can easily scale based upon metadata. A PaaS, such as OpenShift by Red Hat, can simplify this functionality.     
  • Service Discovery: In a microservice world, multiple services are typically distributed in a PaaS environment. Immutable infrastructure is provided by containers or immutable VM images. Services may scale up and down based upon certain pre-defined metrics. The exact address of a service may not be known until the service is deployed and ready to be used.
    The dynamic nature of a service’s endpoint address is handled by service registration and discovery. Each service registers with a broker and provides more details about itself (including the endpoint address). Other consumer services then query the broker to find out the location of a service and invoke it. There are several ways to register and query services such as ZooKeeper, etcd, consul, Kubernetes, Netflix Eureka, and others.     
  • Service Monitoring: One of the most important aspects of a distributed system is service monitoring and logging. This enables one to take proactive action if, for example, a service is consuming unexpected resources. The ELK Stack can aggregate logs from different microservices, provide a consistent visualization over them, and make that data available to business users. Other possible tools for distributed logging are Syslog, Logentries, and Loggly.     
  • Resiliency: Software failure will occur, no matter how much and how hard you test. This is all the more important when multiple microservices are distributed all over the Internet. The key concern is not “how to avoid failure” but “how to deal with failure.” It’s important for services to automatically take corrective action to ensure user experience is not impacted. The Circuit Breaker pattern allows one to build resiliency in software—Netflix’s Hystrix and Ribbon are good libraries that implement this pattern.     
  • DevOps: Continuous Integration and Continuous Deployment (CI/CD) are very important in order for microservices-based applications to succeed. These practices are required so that errors are identified early, and so little to no coordination is required between different teams building different microservices.   
               Section 6      
    Good Design Principles for Existing Monoliths

          Refactoring a monolith into a microservices-based application will not help solve all architectural issues. Before you start breaking up a monolith, it’s important to make sure the monolith is designed following good software architecture principles. Some common rules are:
   
         
  • Practice separation of concerns, possibly using Model-View- Controller (MVC)     
  • Use well-defined APIs for high cohesion and low coupling     
  • Don’t Repeat Yourself (DRY)     
  • Use Convention over Configuration (CoC)     
  • Separate interfaces/APIs and implementations, and follow the Law of Demeter. Classes shouldn’t call other classes directly just because they happen to be in the same archive     
  • Use Domain-Driven Design to keep objects related to a domain/component together     
  • Don’t build something that you don’t need now (YAGNI—You Aren’t Going to Need It)   
               Section 7      
    Refactoring a Monolith to Microservices

          Consider a Java EE monolithic application that is typically defined as a WAR or an EAR archive. The entire functionality for the application is packaged in a single unit. For example, an online shopping cart may consist of User, Catalog, and Order functionalities. All web pages are in the root of the application, all corresponding Java classes are in the WEB-INF/classes directory, and all resources are in the WEB-INF/classes/META-INF directory.
     
Getting Started With Microservices-1 (commercial,containers,efficiency,management,describes)

     Figure 1:Monolith Architecture
    Such an application can be refactored into microservices, which would create an architecture that would look like the following:

Getting Started With Microservices-2 (commercial,containers,efficiency,management,describes)

     Figure 2:Refactoring to Microservices
   
         
  • The above application is functionally decomposed where User, Order, and Catalog components are packaged as separate WAR files. Each WAR file has the relevant web pages, classes, and configuration files required for that component.     
  • Java EE is used to implement each component, but there is no long term commitment to the stack, as different components talk to each other using a well-defined API.     
  • Different classes in this component belong to the same domain, so the code is easier to write and maintain. The underlying stack can also change, possibly keeping technical debt to a minimum.     
  • Each archive has its own database (i.e. data stores are not shared). This allows each microservice to evolve and choose whatever type of data store—relational, NoSQL, flat file, in- memory, or some thing else—is most appropriate.     
  • Each component registers with a Service Registry. This is required because multiple stateless instances of each service might be running at a given time, and their exact endpoint locations will be known only at the runtime. Netflix Eureka, etcd, and Zookeeper are some options for service registry/ discovery.     
  • If components need to talk to each other, which is quite common, then they would do so using a pre-defined API. REST for synchronous or Pub/Sub for asynchronous communication are the most common means to achieve this. In this case, the Order component discovers User and Catalog service and talks to them using a REST API.     
  • Client interaction for the application is defined in another application (in this case, the Shopping Cart UI). This application discovers the services from the Service Registry and composes them together. It should mostly be a dumb proxy (discussed in a later section), where the UI pages of the different components are invoked to display the interface. A common look and feel can be achieved by providing standard CSS/ JavaScript resources.   
     More details can be found at: http://github.com/arun-gupta/microservices .
               Section 8      
    Patterns in Microservices

          1. Use Bounded Contexts to Identify Candidates for Microservices

    Bounded contexts (a pattern from domain-driven design) are a great way to identify what parts of the domain model of a monolithic application can be decomposed into microservices. In an ideal decomposition, every bounded context can be extracted out as a separate microservice, which communicates with other similarly-extracted microservices through well defined APIs. It is not necessary to share the model classes of a microservice with consumers; the model objects should be hidden as you wish to minimize binary dependencies between your microservices.
    The use of an anti-corruption layer is strongly recommended during the process of decomposing a monolith. The anti-corruption layer allows the model in one microservice to change without impacting the consumers of the microservice.
123下一页
友荐云推荐




上一篇:Leaked Samsung Chromebook Is Delightful Overkill
下一篇:因身材矮小、气势不足,所以去健身,如今成健身教练,坐拥几十万粉丝,后创办FitTime ...
酷辣虫提示酷辣虫禁止发表任何与中华人民共和国法律有抵触的内容!所有内容由用户发布,并不代表酷辣虫的观点,酷辣虫无法对用户发布内容真实性提供任何的保证,请自行验证并承担风险与后果。如您有版权、违规等问题,请通过"联系我们"或"违规举报"告知我们处理。

hhnphobw 发表于 2016-10-17 23:40:28
不错 支持一个了
回复 支持 反对

使用道具 举报

思恋逃离回忆丶 发表于 2016-10-18 02:48:38
好贴,好贴,必须顶一个!
回复 支持 反对

使用道具 举报

米果1 发表于 2016-10-18 04:16:17
是金子,总会花光的;是镜子,总会反光的……
回复 支持 反对

使用道具 举报

恏聚恏散 发表于 2016-10-20 10:30:37
支持,赞一个
回复 支持 反对

使用道具 举报

火红火 发表于 2016-10-21 03:02:05
夏天就是不好,穷的时候我连西北风都没得喝……
回复 支持 反对

使用道具 举报

看俺Q915409190 发表于 2016-10-28 10:29:05
今年楼主不送礼,送礼就给楼下的!
回复 支持 反对

使用道具 举报

李孟秋 发表于 2016-10-29 06:52:34
爱我的人请继续,恨我的人别放弃.
回复 支持 反对

使用道具 举报

天气不错coe 发表于 2016-11-3 00:43:09
不是我劝着我自己,我特么早和这个世界翻脸了。
回复 支持 反对

使用道具 举报

*滑动验证:
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

我要投稿

推荐阅读

扫码访问 @iTTTTT瑞翔 的微博
回页顶回复上一篇下一篇回列表手机版
手机版/CoLaBug.com ( 粤ICP备05003221号 | 文网文[2010]257号 )|网站地图 酷辣虫

© 2001-2016 Comsenz Inc. Design: Dean. DiscuzFans.

返回顶部 返回列表