Overview of. Net distributed cloud platform basic service construction,. net Overview

Overview of. Net distributed cloud platform basic service construction,. net Overview

1) Background

Build the basic framework of the cloud platform to support the construction and development of various cloud services.

2) Basic Services

Based on the current understanding of the business and the development direction, the following basic services are abstracted,

 

3) Summary

The development of basic services will be adjusted and improved based on the business development, and will also be continuously improved, evolved and improved. Of course, according to the current situation of the company and the degree of urgency for basic services, the positioning and development expectations of basic service modules are as follows.

1)Database Middleware

Company status quo:

1) there is an urgent need to support multiple types of databases, such as mysql, orcale, and sqlserver. You can switch between multiple database types by modifying a few codes at most.

2) do not allow developers to write SQL code as far as possible, because the original developer development method adopts the linq method, and most of the developed businesses are winform businesses.

Solution:

Currently, the entity framework is used. Because the entity framework is programmed in the linq mode, it can parse the SQL into SQL and be compatible with queries of multiple database types. Entity framework is popular in. net, with open-source code and fast version development, and has a large number of application documents and learning materials. It is preferred for frameworks of the same type.

Disadvantages:

The adoption of Entity framework is only a temporary solution, because the business needs will last for a long time.

1) from the perspective of high-performance services, the process of writing to SQL will inevitably suffer performance losses. Even if the Framework performs resolution caching, these problems cannot be avoided. For complex statement queries, unexpected parsing results can also be found in linq to SQL, which is difficult to be expressed in linq. If you are not familiar with the performance of this method, writing will also cause performance problems.

2) from the database perspective, the current business is still using the same database. In the future, the business will adopt multiple databases and multiple data tables. This entity framework will be followed by database sharding and table sharding support. Obviously, even modifying the source code is a headache. In addition, the support of multiple data sources and multiple database types means that the same service involves performance tuning and O & M for multiple databases, especially data migration involving version upgrades. It must be compatible with multiple databases, this means that the workload is really huge.

Future Direction:

If a single type of database is used, a distributed database that supports SQL writing and direct connection to the database, supports database sharding and table sharding, automatically manages the database connection pool, and automatically provides database middleware such as performance analysis and warning.

 

2)TCPService Framework

Company status quo:

1) it is used to collect programs, collect direct connections between devices and servers, and send collection information.

2) the server sends a reverse notification to the connected program or device to notify the device in real time.

3) The communication environment with the workstation (the cloud platform uses ActiveMQ) to connect to a third-party device (using signalr asp.net ).

Solution:

Temporarily maintain the communication environment with the workstation (the cloud platform uses ActiveMQ) to connect to a third-party device (using signalr integrated into asp.net. Because the company currently uses C # programming, there are some examples of the corresponding C # client or C # solutions for the two technology models. Therefore, the problem should not be solved, but there are no fewer problems. If you encounter performance problems, you can simply expand multiple ActiveMQ and load balancing of the Application Service.

Other solutions:

Using similar solutions such as redis or rabbitmq, I personally prefer to solve this problem with the redis publishing and subscription mechanism. The performance is not poor (I have heard of large-scale use cases and cross-language client sdks) (The Cache Usage framework can be unified for easy maintenance .)

Disadvantages:

1) No matter which Message Queue methods such as redis, activemq, and rabbitmq are used to solve the performance problems, these frameworks are used to solve message queues, because of its memory message forwarding mechanism, it is used for some instant messaging and is often used to solve some application interactions in the Intranet environment. The current scenario will be applied to the WAN environment to communicate with the workstation. Similar solutions have been used in the industry. However, activemq memory is often full or inexplicably dead.

2) use signalr application mounting to asp.net. After some third-party development experience, performance problems or failures may occur when the concurrency is slightly higher. Signalr is often used in. net technology and has simple use cases, but there are no mature use cases and scenarios.

Future Direction:

Using the NIO idea of java or the port completion idea of Windows, building a pure TCP socket service is an essential solution. Generally, a server can carry 0.1 million connections, there are no problems with thousands of active connections (depending on server configurations) (and the old scheme may carry thousands of active connections, and hundreds of active connections may have performance problems ).

 

3)Certification Center

Company status quo:

1) login verification of the Intranet subsystem of the original workstation, Internet device login verification, and cloud platform user login verification.

2) Obtain menu permissions and operation permissions of users on the cloud platform.

Solution:

A self-developed certification center platform for the company's specific business. Currently, it is only the first version. Include

1) device management, Subsystem Management, cloud platform user management, and permission management

2) third-party logon interfaces, user menu permission interfaces, and user operation permission interfaces.

The above functions can currently meet the business needs of existing companies.

Disadvantages:

1) At present, it is relatively simple to use token authorization, anonymous encryption, and authorization without appid and serect keys. Therefore, there is no strong security mechanism, but it can meet the needs of actual development. In addition, the current business does not have high security requirements.

2) The communication performance is not high because Http is used for communication, and the communication performance is not high. In addition, the authentication center will perform authentication for all services. Basically, all cloud project modules and other services will aggregate requests to the authentication center interface, in the future development of the company's traffic, there will inevitably be the first interface performance problems.

Future Direction:

1) All the interfaces on the platform must be implemented with redis cache. The platform interface client must be encapsulated with sdks (the client cache should be implemented within the sdk, even if the default cache is 5 s)

2) All interfaces of the platform are subsequently connected to the "high-performance service center" and implemented through the TCP connection pool communication mode to improve the internal communication performance.

4)Service Center (Personal Open Source Address: http://git.oschina.net/chejiangyi/Dyd.BaseService.ServiceCenter)

Company status quo:

1) there is a service coupling between projects that calls each other. Currently, the dll method is used for calling, but dll update errors and management may occur, leading to low efficiency for developers.

2) the company is eager to adopt the microservice/soa architecture to strip the business coupling of the project and simplify the management of upstream and downstream business calls.

Solution:

1) currently, the service-oriented interfaces are provided in a way similar to Http restful for third-party interfaces to be called. This is also in line with the soa service architecture.

2) api view automatically exposes api documentation to facilitate communication and coordination between upstream and downstream developers.

Disadvantages:

1) Personal experience: the service-oriented interface is effective and helpful for business communication, but it may not be able to actually improve the efficiency. However, modular management of projects should be helpful.

2) The communication efficiency of Http interfaces is not high. As a service framework, the internal communication of TCP is required, so that the performance can be significantly improved.

3) service governance and coordination issues are considered. If the call chain dead loop is not considered, the performance of the call chain leads to an avalanche, upstream and downstream service monitoring, historical records and notifications of changes to upstream and downstream client services, coupled strip of upstream and downstream client service protocols, Server Load balancer and Failover at the service level, and many other issues.

Future Direction:

1) The self-developed service center abstracts performance, service governance, coordination, and other work from business development. Business Development only needs to focus on stateless business service development.

2) All internal services are stripped (not just coupled services) and migrated to the Internal Service Center. If internal services need to be disclosed to third parties, the open gateway service of Http can be provided for calling. The Gateway layer performs some authorization management and other work, and the gateway performs load balancing.

5)Unified monitoring (Personal Open Source Address: http://git.oschina.net/chejiangyi/Dyd.BaseService.Monitor)

Company status quo:

1) The project is in the early stage of research and development. There are no large-scale Server Clusters, no multi-version interface compatibility, no online monitoring problems, online troubleshooting problems, and performance problems, I am not familiar with and sensitive to these situations.

2) developers hope to solve the stack problems of error logs and error logs during project development and debugging, and troubleshoot the call Path Problems.

Solution:

1) The use of Http Restful service interfaces should alleviate the problem of project development and debugging. (I have never encountered any problems in development and debugging before. It should be caused by the use of wcf in the original architecture and technology)

2) Build a distributed monitoring platform because it is an open-source project, which is not difficult to use. It can handle many cloud server management, performance monitoring and warning, SQL Performance monitoring, api interface performance monitoring, and unified error logs.

Disadvantages:

1) I personally do not know exactly why the log problem is really urgent during the current project developer debugging project development process, there is no profound experience (there have been no problems difficult to debug since the development, and the existing company's project architecture may be closely related), so I don't know if it can be solved.

2) Currently, the distributed monitoring platform is a simplified version developed by the original company. It is developed to achieve the abstraction and layout of the entire project architecture monitoring module. There is still much room for optimization and improvement in performance and functionality. (Of course, there are more than enough support companies)

Future Direction:

1) continuously improve and improve the monitoring platform based on the monitoring requirements of the company's business.

2) the functions and performance of the monitoring platform must be improved. The underlying layer will be stored and implemented using nosql.

6)Configuration Center (Personal Open Source Address: http://git.oschina.net/chejiangyi/Dyd.BaseService.ConfigManager)

Company status quo:

1) At present, the company has a function similar to the configuration Center for basic business configuration, which is relatively simple.

2) The cloud business is still in a simple business model and business State, without the need for truly complicated online business and business divestiture, and asynchronous functions, the essential requirements and problems of the distributed configuration center have not yet been truly exposed.

Solution:

The original configuration center function is still used, and the distributed configuration center is also set up. The original configuration center is suitable for business configuration storage. The existing configuration center can be used for business configuration storage, or for Environment configuration coordination issues in the distributed architecture.

Disadvantages:

It will maintain the O & M of the two configuration centers, which is difficult to differentiate in the Business Architecture and easy to confuse in the business.

Future Direction:

1) The two configuration centers will be integrated to a certain extent based on business needs and directions. However, the current company will not focus on this.

2) The configuration center will continue to develop more functions based on the company's business development, but it is unclear for the time being.

7)Message Queue (Personal Open Source Address: http://git.oschina.net/chejiangyi/Dyd.BusinessMQ)

Company status quo:

1) At present, the company uses ActiveMQ for asynchronous communication between the cloud platform and the workstation.

2) The Cloud Platform project is still in the initial stage of R & D, with insufficient business complexity, low performance requirements, and asynchronous splitting and decoupling of the same service.

3) The company's collection business has not yet achieved real large-scale analysis, large-scale collection scenarios.

Solution:

Considering the unified architecture of the company, ActiveMQ is currently used to facilitate cross-language asynchronous communication such as java and C. Of course, it can only apply the simple instant communication effects of Asynchronization.

Disadvantages:

ActiveMQ can only be used as an asynchronous instant communication service for the time being. Its current performance and stability are not a long term.

1) For persistent Tcp communication, we will build a TCP service in the future.

2) For the purpose of Message Queue communication, the message accumulation performance, high stability and high reliability will be considered in the future (messages cannot be lost ).

3) if the message queue is used to collect messages for subsequent collection and analysis, more solutions similar to kafka will be considered in the future.

Future development:

MQ has many solutions and many features suitable for different business scenarios. For these different scenarios and solutions, I will consider the following:

1) A self-built Message Queue platform. The self-built Message Queue can be separated from the underlying storage engine. The features of different storage engines can be used in different scenarios and solutions. (For example, the storage engine is redis, ssdb, and database. Even if the logic is the same, but the performance is different, the reliability performance is also different)

2) A set of self-built message queue middleware that can strip the Specific Message Queue implementation and abstract the usage of the conventional message queue. You can switch between different message platforms by modifying the connection string or configuration class. (For example, the underlying message service may be activemq, rabbitmq, redis, and kafka, which can be transparent to upper-layer services or even seamlessly switch between them)

8)Task Scheduling platform (Personal Open Source Address: http://git.oschina.net/chejiangyi/Dyd.BaseService.TaskManager)

Company status quo:

1) the company's business is still in the early stage, and there are no business requirements such as background task statistics and background task consumption.

2) The task scheduling platform is a basic link of all basic services and is currently only used in basic service deployment.

Solution:

A personal Open-Source Distributed Task Scheduling platform.

Disadvantages:

The Distributed Task Scheduling platform is currently only a simple task scheduling platform, and there is still much room for future development.

Future development:

1) All company businesses are regarded as one business task, and all business tasks are mounted to the task scheduling platform. The task scheduling platform will be based on the load of distributed clusters, automatically allocate cluster servers for scheduling and coordination of service load balancing, failover, and other resources. (For example, all interface services, all background tasks, and all message consumption tasks)

2) The task scheduling platform is also called a big data processing platform similar to hadoop. It is used for batch processing of real-time, non-real-time dynamic stream task creation, recycling, and coordination. (For example, collection services such as crawlers and algorithm analysis tasks)

9)Distributed cache (Personal Open Source Address: http://git.oschina.net/chejiangyi/XXF.BaseService.DistributedCache)

Company status quo:

1) At present, the company's business does not need to use distributed cache. In addition to the authentication center, this should involve some performance problems in the future.

Solution:

I personally open-source distributed cache middleware. (Currently, a unified distributed cache framework based on the memcached protocol is implemented)

Disadvantages:

Only supports the basic distributed cache framework. The overall data structure is relatively simple (key + timed expiration failure), but it is also the most practical function in cache.

Future development:

1) supports more protocols, such as redis communication protocols. And more abstraction of the underlying storage framework. (Each cache framework has specific application scenarios and subtle differences)

2) centralized performance monitoring of distributed cache; Support for consistent hashing facilitates customization of failover solutions to avoid cache failure scenarios such as avalanche.

3) supports other cache scenarios based on the company's business, such as local cache consistency (Collaborative distributed Message Queue implementation.

10)File Service

Company status quo:

1) information collected by the company is stored on local application servers and stored as files.

2) the company's collection business information files must be kept permanently.

Solution:

Currently, the status quo is maintained.

Disadvantages:

1) from the perspective of capacity expansion and performance, individual file servers are a long-term requirement.

2) The current business may involve the continuous storage of files and the reading of part of the file content. The open source file service on the market may not meet the requirements.

3) I am not particularly familiar with the company's business requirements on file services.

Future development:

1) Considering the self-developed distributed file service, the read performance may not be better than the municipal open source file service. (The self-developed file service should still be based on the windows file management structure), but the flexibility will be higher.

2) The self-developed distributed file service sdk must be abstract and compatible with the company's underlying storage differences (some large file storage may still use third-party storage, but it is transparent and imperceptible for development ).

11)Log Platform

Company status quo:

1) the company's current difficulties in project debugging lead to requirements for the log platform.

2) the company's business does not require log-based analysis at the moment. It also requires logging of large-capacity logs and logging of stack call chains based on logs.

Solution:

Currently, the error log of the monitoring platform and the local Error Log are printed to solve the current error debugging requirements.

The monitoring platform also supports printing regular business logs, but the printing of this business log does not support large capacity requirements. (Too many prints will cause program blocking)

Disadvantages:

1) The monitoring platform also supports printing regular business logs, but the printing of this business log does not support large capacity requirements. (Too much printing will cause program blocking ).

2) logs and Analysis of call chains are not supported. It does not support large-capacity log records, and does not support millisecond-level log searches, making it easy to locate problems.

Future development:

1) log platform will be independently developed in the future (or combined with third-party open-source), similar to the current open-source elk. The platform is positioned to collect, mine, analyze, and troubleshoot large volumes of logs.

2) It is more about combining its own business and planning for future business development, and providing specific functions or statistical report presentation for the basic functions of the log platform.

12)Open interface platform (Personal Open Source Address: http://git.oschina.net/chejiangyi/ApiView)

Company status quo:

1) the company's business urgently needs to provide interfaces through soa/microservices for third-party developers to use.

2) documents need to be maintained between upstream and downstream Soa businesses for easy communication and debugging.

Solution:

Personal open-source appview open interface platform. Similar to swagger.

Disadvantages:

Currently, the open interface platform is easy to implement, and its functions are also very simple and common. There are still some management functions, such as version change records and upstream and downstream version change notifications.

Future development:

1) The open interface platform constantly improves functions based on the company's actual problems and needs, such as automatically detecting and reminding nonstandard interfaces according to the company's interface conventions. Automatically record version changes, automatically notify downstream callers of interface changes by email, and automate interface governance.

 

13)Distributed deployment Platform

Company status quo:

1) the company's cloud platform business is still in its infancy, with far fewer traffic and no performance problems.

2) The deployment of the cloud platform does not take into account the distributed deployment and O & M issues, nor does it require second-level full platform deployment, version management, and version rollback.

Solution:

For the time being, manually release multiple servers.

Disadvantages:

Artificial solutions often cause many problems in the real environment. After all, people are the easiest to make mistakes. Therefore, after the company goes on track, it often uses automatic deployment and release.

Future development:

1) independently developed a distributed deployment and Release Platform for version management, exception rollback, and distributed deployment. (This implementation is not complex. It is enough)

14)OpenApiGateway

Company status quo:

1) Currently, the company uses the WCF method to publish services. debugging and use are troublesome.

Solution:

1) We will use http to directly expose soa service to solve the problem. This method is crude but effective.

2) after the development of the service center is stable, all services will be migrated to the service center. All services will be accessed through the tcp connection pool to improve the communication efficiency and improve the performance and response time.

Disadvantages:

1) third-party developers often do not support access through third-party APIs.

Future development:

1) Open api Gateway: All Intranet Service APIs can be forwarded and accessed through Http. The Http gateway maintains high-performance communication with the service center.

2) When the api gateway is enabled with performance problems, load balancing is enough.

3) Open api gateway manages open api authorization issues, api Access Frequency Control, api access permission control, and api access protocol control (xml or json ).

Remove the Open api management function and the specific service implementation of the api.

 

4) Summary

Due to the limited time budget, the above content is a rough description of the positioning and architecture direction of the current basic service platforms, and there is no re-proofread of the text;

In the future, the business development is always changing, so the functions and directions of basic services will be constantly fine-tuned, but the overall direction should not change. We hope that a rough document will help you understand the trade-off between the company's business architecture and the future evolution direction.

 

 

By che jiangyi

(Note: you are welcome to share your ideas and point out the shortcomings of the architecture. tks !)

Open source QQ group:. net open source basic service 238543768