SOA architecture designed for the corporate sector

New to the eldest brother meeting said: fellow students, the company's business more and more heavy, the next few years to multiply growth ..., we have to comb out a new structure, to better support n million users ..... Beat.....
Think of a little excited about it, so the new year when the landlord while waiting for blind date sister paper bored, reflect on the current system status, the concept of the design of the following structure.

Read the catalogue:

1. Existing systems
2. New architecture
   2.1 Logical architecture Diagram
   2.2 Explanatory Notes
3. System implementation
   3.1 SOA Management Center
   3.2 Publishing Services
   3.3 Subscription Services
   3.4 Samples of mushroom mining
4. Design goals
   4.1 As little intrusion as possible.
   4.2 Service autonomy && level expansion
   4.3 System upgrade downgrade
5. Problems
   5.1 Clientapi VS Serviceapi
   5.2 Aggregation Services
   5.3 Service Ratings
6. Summary of the Experience

Existing systems

Humble division business is heavy, the system is also some years, the research and development team, the system is more stable. So not bad is not too good, in short, can also meet the existing needs. But nearly 2 years, the mobile internet and other big line, the eldest brothers are also moved, began to sharpening. and the existing system to deal with complex changes, in some places quite inadequate:

• Interface does not have unified management
• Many components cannot be reused/re-made wheels
• Inter-module responsibilities unclear, coupling too deep
• The problem is slow to troubleshoot the joint
• Insufficient pre-development planning to form accumulation
• Lack of API specification/documentation Less

New architecture

Logical architecture Diagram:

View larger image

Explanatory notes:

• A start: Is the system level and can be deployed independently. Can be hosted on the Iis/windowsservice and other above.
• B Start: Is the module level and cannot be deployed independently. Relatively independent function modules, but not small, so attached to other systems or with a plurality of modules to form a subsystem. The module level can be divided into multiple tiers in the project and can be upgraded to subsystems based on fractions (see system upgrade downgrade).
• C Start: Is the component level and cannot be deployed independently. Most are public components, which are typically separate class libraries that are used by DLLs. Some open source components are also grouped here, for example: Aufofac,fluentdata. You need to build your own NuGet server for unified version management.
• The number following the letter: is the level representing the service, see service rating.
• System communication: As far as possible between the system intranet WCF/TCP, foreign cooperation units and the mobile end of the webapi/http.
• Transmission format: Protobuffer, Json.
• Data exchange: Priority through the data service interface, followed by SSIS, Job.
• Base platform: Cache Redis, queue RABBITMQ, etc. Depending on the abstraction, the framework can be replaced.
• DB Layer: Each subsystem has its own sub-DB, which in principle cannot be read across the library.
• High Availability: The subsystem does its own load and service change notification uses zookeeper.
• One-way Level 2: subscription service only, cannot publish the service, Level 2 can only subscribe to Level 2 service.
• Fixed point: A client can only subscribe to a service provided by a server.

System Implementation SOA Management Center

This is a core part of the new architecture, with the following main features:

• Provides a publish/subscribe/serviceadapter component
• Provides a web management interface
• Various configurations for service access
• Service current limit/alarm at peak times
• Service Access Authorization, description

Publishing services

Each system is published through a Web Management page for service configuration.
You can also configure publishing by using the components that are available in Central administration:

    protected voidApplication_Start () {Servicepublisher.pushlish (NewServiceConfig () {ServiceName="get a reservation form details", Qps= +, level=1, Key="xxxx-yyyy", Source=Subscribesource.all, Serviceaddress="/order/getdetail",            //other        }); } [Servicefilter]voidGetdetail () {}

Subscription access Services

Each system uses the components provided by the central administration to get the subscribed service, then accesses the interface through the adapter, and the service change is done in the heartbeat:

    protected void Application_Start ()    {        // get a list        of services var servicelist = servicemanager.getservicelist ();        Globalservice.servicelist=servicelist;    }     void Heartbeat ()    {        var servicelist = servicemanager.getservicelist ();        Globalservice.servicelist=servicelist;    }    Serviceadapter.access (globalservice.servicelist[0]);

Mushroom Picking Example

Design goals as few intrusions as possible

This is very important, if not good reuse of existing systems or intrusive too strong, will inevitably lead to:

• The new architecture cycle is too long, long-term maintenance of two sets of structures. In this case, the cost is too high, the poor implementation or has not been implemented has been cut.
• The resistance of the developers, every ape has a quite unruly temper, the ability to build wheels, the dream of restructuring the world .... If it's too complicated and too restrictive, God knows what your apes will do!

Based on this consideration, service distribution rather than service centralization is adopted.

• Each system, when needed, subscribes to the service and then pulls the service address/myneedservcie.list.
• Then through the Serviceadapter Access service, Serviceadapter will do some checks such as permissions.
• Adding servicefilter,fileter on the service will do the permission checksum and the service is called to collect the information.
• Then add the service, document description in central Administration.

The advantage is: a system and B system is directly interactive, service calls do not take transit routing, performance. The function of a component is only an auxiliary constraint.

Service autonomy && level expansion

Due to the small intrusion, the service changes between the various systems are maintained by the respective research and development teams.
the communication between the system does not go service , the direct internal call. Calls are accessed through the Serviceadapter component, Serviceadapter contains packages for in-process, WCF, WEBAPI, and so on, which makes it easier to replace them later with other services. Services in the expansion of the management center is not controlled, self-made load, increase the server.

System upgrade downgrade

When there is a new need to come, depending on whether the product needs to be deployed independently, and the existing system coupling factors, such as to assess the module level or system level.
For older modules, scores are evaluated based on importance, number of visits, and so on. The standard is extracted from the subsystem by the module, separately managed.
Also for the old system, the non-conformance of the downgrade processing, reduced to a module integration into other systems.

This is really important, and if you do not evaluate the project, it will often lead to a system becoming more and more heavy. The end result is that maintenance is getting more and more troublesome and often problematic. Finally forced to push to re-start, the cost is larger, of course, the cost of the old General Assembly to consider more. In this case, the apes will spit on the same slag as before, while trying to prepare for the show, let you see what is called DDD, TDD, design patterns ....

The premise is that in the development of requirements, according to the module sub-layer rather than the entire large layer , so as to facilitate collaborative development and extraction of subsystems.

Frequently asked Questions Clientapi VS Serviceapi

Clientapi this in the earlier use of more methods. The advantages are obvious: simple and quick, install references from NuGet. This will be more and more problematic later.
With cache Redis, multiple systems use clients to access Redis servers directly. If there is a number of system connections forget to shut down, it will affect the entire large system, because the client permissions are too large, clients can directly manipulate the Redis server. In this case the Redis server itself is exposed, even if the client package is no better, as long as the communication protocol specification, you can write their own client connection (see: C # Implementation of Redis Client (a)). This communication period cannot be controlled, can not be intercepted, the same queue and other also the same situation.

SERVICEAPI:

We add a layer in the middle, control in the cache system, also rely on abstraction, redis replaceable. The caching system is published to other systems for use as a service. What can not be avoided is the loss of performance, of course, this loss may be reduced by some means.

Aggregation Services

The granularity of the service has always been a headache for SOA design. It's too rough to reuse, too fine. Multiple round trips are required, and the performance, transaction processing is a problem. For example, the next order service, the process includes the creation of user data, create booking orders, payment order, update account relations, update inventory and a series of operations. This is a coarse-grained service that contains fine-grained services provided by several subsystems. Coarse-grained services, multiple subsystems can not avoid mutual interaction, long-term will make the system too heavy, become responsibility confusion.
Service Design Criteria is to let the service high cohesion, service between loose coupling, clear boundaries. So we're pulling away from a converged service system, which is dedicated to consolidating the fine-grained services provided by each system for front-end use. and other systems only do what they are responsible for. In the aggregation service system, it is convenient for us to control the granularity of the service and improve the service reuse.

Service Rating

When collaborating with multiple research and development teams, it is difficult for everyone to be familiar with all business. Therefore, in order to avoid service call confusion, and even cyclic dependent calls, the service is added to the rating.
As shown in the figure, Level 1 service can not be adjusted 2 levels of service, that is, low level can not be advanced, advanced adjustable low-level, peer adjustable.
This level is divided for individual services. For example, there is an update inventory service, it has no externally dependent services, just update its own db, so that we can divide it into a Level 1 service. And our aggregation service system has an order coarse granularity service, it calls the update inventory service internally, then it is a Level 2 service. It is clear that level 1 here should not call Level 2, which is also the purpose of service grading.

Summary of the Experience

• Good architecture is constantly evolving.
• Consider every detail as much as possible
• Focus on overall balance, not local optimization
• Relies on abstraction, not specifically which framework technology
• Consider a person, and consider which technology to use.
• Don't think about the program when you get along with sister paper.

SOA architecture designed for the corporate sector