当前位置:网站首页>Use dapr to shorten software development cycle and improve production efficiency

Use dapr to shorten software development cycle and improve production efficiency

2022-07-06 11:03:00 Dotnet cross platform

Microsoft DevOps Articles in the document (https://docs.microsoft.com/zh-cn/azure/devops/report/dashboards/cycle-time-and-lead-time?view=azure-devops) This picture in introduces us   What is cycle time   as well as How it affects my project flow Very influential .

7b82dffcd52d7e4a717e23b5a7c1c501.png

Input... For the first time " Underway " or " resolved " Status category to input " Completed " Status category , Calculate cycle time . When developers write code , Being able to quickly validate changes and make revisions is critical to maintaining a short cycle time .

Naiichi Ono, the father of Toyota production mode, once said : The only thing we need to do is to reduce the cycle time from receiving orders to delivering products to customers . The reduction of cycle time can effectively ensure the timely delivery of software . So cycle time is the core goal of software delivery .

Especially the design and development of microservices , It is usually necessary to achieve the following 4 Goals :

  • Built API Microservices that drive design

  • Everything can be built locally 、 Testing and running , Without complicated setup .

  • Equivalence between cloud and local dependencies

  • The equipment environment is irrelevant , Be free to Windows,Linux,Mac Switch between .

We rely on Dapr It is very easy to achieve the above 4 Goals , Use Docker Compose and Dapr Skills for local development , The test and production environment runs on Kubernetes, Kubernetes Now it is the standard service of major cloud factories . With the help of Dapr The language independence of , Platform independence , We can try to shorten the time in the environment , Maintain a short lead time to deliver software .

We can review our development process in our brain , For each task / Code changes :

  1. Developers will deploy changes to the production environment

  2. If any mistakes are found , Please redeploy the old Mirror image

  3. Fix all changes locally

  4. Push its branches to generate deployable builds , Then return to (1)

Only when developers get out of this cycle , They can check their code into the main program . This process is crazy ! Only the 4 It takes about... Between image creation and deployment 20 minute . Twoorthree missing errors may cost developers about 1 Hours , And consider that in addition to daily work , We are all engaged in this work , This kills productivity . It is also possible to consider the cycle required to deploy changes to dependencies , Deployment here took longer .

So let's start with From the perspective of improving software development productivity ,Dapr Provided Major productivity improvement advantages of yes :

  • Reducing technology debt  - Through the production and use of software , The software encapsulates areas with a high rate of change , Excellent focus separation , And has a wide range of decoupling .

  • Reduce the coding workload required  — By using " Low code " Method realization , The approach is to provide many pre built software components that are usually needed , Especially the components that realize the function of commodity pipeline with low business value , For example, the code that connects Services .

  • Developers are more focused on generating high-value business logic  — By reducing the time it takes to generate commodity pipeline codes and / Or use manual processes and tools that can use automated code .

  • Yes Sharing status Effective coordination of concurrent access  — This well-known difficult area in distributed systems can be used in many cases Actor The model generates this result .

Separate the services of distributed systems , It can make software development 、 Expanding and maintaining software is more time-consuming and cost-effective , It's easier . Why? ? Separating software fragments from each other can make their internal code content and code structure change independently of each other , This greatly reduces the workload required for code changes when requirements change . This decoupling is one of the best ways to reduce technical debt , And keep a low level as the years go by , So as to improve productivity in the long run .

Dapr A key way to generate decoupling is through its building blocks , Each building block defines the conceptual interface of common functions of distributed systems . For most building blocks ,Dapr There are also many pre built plug-in components , Each component implements all or part of the building block interface for a specific instance of the building block concept . Using pre built plug-in components can also reduce the amount of coding required . without Dapr, Developers don't know how many times they have to write roughly the same low-level pipeline code again and again , To connect to and interact with every database or cloud service our code uses ? Use Dapr The building blocks of / Component method , The answer for zero ! Using pre built plug-in components can save a lot of time , Enable developers to focus on higher value work .

If I told you ,Dapr Is a for distributed systems Swiss Army knife utility service , You may want to find Dapr Many functions of , Because it is both an intermediary and a decoupler .Dapr Provide The main function of as follows , Many of these functions are implemented through building blocks and components , But not all :

  • State storage  — Dapr As the key / The value pair state storage building block defines a conceptual interface , Then there are many pre built plug-in state store provider components , Each component is connected to a specific external key value pair state store , Such as Redis Storage or other popular keys / Value pair database .Dapr State Store The purpose of is to provide low latency storage , Caching . Support for general storage or database management systems , See resource bindings and triggers below .

  • Pub/Sub — Similar to state storage ,Dapr For the release of / The subscription building block defines a conceptual interface , There are also many pre built plug-in releases / Subscription component , Each component is connected to an external release / Subscribe to messaging services , for example Azure Service bus theme or Redis flow .

  • Secure confidential access  — Same idea as above , But it is suitable for all kinds of external confidential storage , Such as key vault .

  • Resource binding and triggers  — Same idea as above , But applied to various external resources ( Many are cloud resources ), Such as queue 、 Event center 、 Service Grid 、Blob Storage 、 Some databases, etc .

  • Service to service invocation  — This building block allows "Daprized" Service pass RPC Address with service name plus method name ( Not through HTTP or gRPC Address ) Mutual communication . This separates service to service communication from specific network endpoints . This is required when using cluster computing hosts , And using other hosts can also save time .

  • Actor — This building block allows each "Daprized" Service usage Actor Model to take advantage of its unique characteristics :1) Code that maintains state and operates state in the same entity , as well as 2) " Round based concurrency ", To prevent multiple clients from using the same Actor When the state is not synchronized .

  • Observability  — Observable building block concept interface provides service to service interaction flow in distributed system ( Include details of various components ) Keep track of 、 Indicators and health monitoring , And sending data to an external aggregator , for example Azure Monitor、Application Insights and Zipkin.

  • Effective security  — stay "Daprized" The breadth and depth of services and the whole collaboration "Daprized" The service system provides a high level of usually configurable security .

  • Middleware pipeline  — Allows you to customize... Declaratively " Middleware pipeline components " Code " Insert " To Dapr request / Response processing pipeline . This allows Dapr Choreograph developer defined services and Dapr Custom processing of communication between , vice versa . for example ,Dapr A ready-made OAuth 2.0 Middleware pipeline components .

  • Great scalability  — This is because Dapr The decoupling 、 Interface based design , And its component plug-in architecture . Please note that , In a given building block , Developers can write their own code to achieve customized Dapr Components .

  • HTTP and gRPC signal communication , And right most Popular programming languages and Cloud provider support .

Please note that , All the pre built plug-in components mentioned above are also configurable ." Insert " The behavior of a specific component is simply to provide declarative configuration files in the standard component directory .Dapr Responsible for loading component code and " Hook up " The work needed .

If I told you Dapr It's a Sidecar, You will know , Usually Dapr A single instance of is paired with a single instance of the service , Each instance runs in its own process .Dapr At present, it is not a code base .Dapr Sidecar Instance and the service instance that uses it pass HTTP or gRPC( Use HTTP2) Communicate with each other across their process boundaries , Here's the picture Shown . When you compare a service instance with Dapr Sidecar When pairing , You are essentially "Daprize" Your service .

Besides , Every Dapr Sidecar All instances know collaboration "Daprized" Serve all others in the system Dapr Sidecar example . All these collaborations Dapr Sidecar Examples use gRPC In a separate Sidecar The dedicated communication channel completely communicates with each other in the background , As shown in the figure below . In this way Dapr Sidecars Communication between is Dapr Of Pub / Sub, Service invocation and Actor The key of model function .Dapr Sidecar And use Dapr Sidecar The service of the instance usually runs in a separate container , Or run as a separate independent process .

6fafb8326f7bc1edd10a451b90a4a539.png

"Daprized" Services are usually only private to their individual Dapr Sidecar Interaction , Pictured above Shown , Put all the messy pipeline details and how to connect with other services 、 Storage 、 Knowledge of confidential and other communications is left to Dapr Sidecar In itself , as well as Dapr Sidecar Examples of Dapr Components . This makes the service code less complex , And the business logic code in the service is similar to Dapr Sidecar And the pipeline logic code in its components ( Also known as infrastructure code ) Provides a good separation of concerns . In the picture above in , Yellow services contain all business logic , And pink Dapr Sidecar Include most of ( If not all ) Pipeline code . This separation of concerns between business logic code and pipeline logic code uses Dapr One of the keys to the significant reduction of technical debt . therefore , When demand inevitably changes , Generally, the code that needs to be changed is much less than the mixing and interweaving of pipeline code and business logic code .

Last , Achieve a high degree of separation of concerns between business logic and pipeline code , Plus components , The developers will More time to focus on high-value business logic , And spend less time on low value component pipeline code . Although low-level piping specifications are absolutely necessary , But developing low-level pipeline specifications is complex and time-consuming , And requires a high level of experience - All this requires time and money . contrary , Use pre built " plug-in unit " Components can redirect most of developers' time and skills to developing business logic , So as to generate the value most directly related to the end users of the software .

Now you can see Dapr Sidecar( Plus the components it uses ) How to stand and use Sidecar And all other services in the distributed system , as well as "Daprized" Services can connect to all possible cloud services or local services . This may be a lot of services ! therefore , Understanding "Daperized" The following services 3 There are three main usage scenarios when ,Dapr The role of an intermediary is crucial .

  • Portable Services — Write once / Run anywhere .Dapr Excellent performance in this scheme , Allow developers to simply insert different components of services that interact with external services and resources ( Configure... Declaratively ). Combine services with Dapr Sidecar Instances are placed in separate containers together , Hard coded external dependencies can be highly isolated . This allows the same "Daprized" And containerized services locally 、 Cloud or edge devices ( Such as IoT Field gateway ) Up operation , Without changing the service code . contrary , You may only need to interface with external dependencies Dapr Change the declarative definition of the component . essentially , Containerized Dapr Sidecar Integration with containerized services actually separates all external dependencies of services , So as to achieve the maximum portability with low work cost , To port to different hosting environments or connect to different external services .

  • Multilingual service system . With the help of Dapr Service call for 、 Release / subscribe 、 Secrets and state storage as well as resource binding and triggers , Services written in various languages can communicate with each other , Without having to rewrite a lot of code , Developers don't have to learn many other languages . For the sake of understanding ,Dapr For many popular languages ( Such as .NET C#、Java、JavaScript、Python and Go etc. ) Software development kit is provided (SDK). essentially , Use any supported language and SDK Developers will target the same standardization Dapr Interface to program , Instead of programming for a bunch of temporary languages or external service interfaces . This also facilitates others 2 Use scenarios .

    • Extend the service life of old software It also belongs to this usage scenario . But please pay attention to , Older software must absolutely support its Dapr Sidecar Of HTTP Interaction . If that's the case , that "Daprize" Legacy software may be feasible , To allow it to become a part of the service system more cost effectively , adopt Dapr Sidecar And its building blocks and components communicate with other services and resources .

  • Static services with dynamic dependencies . Need to publish / Subscribe to the message trunk from Redis Change to Azure The service bus ? When the organization needs to adapt to change , This usually happens . Use "Daprized" Service system , And not in use Dapr Rewrite many lines of code ( Implement publishing in many single services / Subscribe to messaging ) Compared with the cost of , Make this change ( That is, change the declarative component definition ) The cost of each service may be quite small . The same applies to other building blocks and their components .

Attention, please. ,"Daprized" Services can be hosted in Kubernetes In the container on the , It can also be hosted in support Docker Wait for another host of the container , Including use in appropriate cases Docker Compose."Daprized" Services can also be hosted , Instead of running on various computing hosts ( Including your own development system ) Use containers as independent processes on .

Throughout the history of software ,Dapr The potential savings in time and labor are really a big deal ! up to now , It's not like Dapr Such things , It can run almost anywhere , It also provides large-scale decoupling with distributed system services , And componentization and excellent separation of concerns . All this reduces the work required for initial development , And in the long run , It also led to significantly lower technical debt than usual . In the short and long run , All of these can significantly improve software development productivity , So as to reduce the workload that needs to be completed , Save time and money .

原网站

版权声明
本文为[Dotnet cross platform]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/02/202202131647373210.html