In the process of business development, the coupling of platform code and business code is difficult to be separated, and the code interweaving between business and business lacks disassembly. Therefore, no matter from the perspective of code quality or team collaboration, it seriously affects the collaborative efficiency and development efficiency between development teams, and ultimately affects the user experience and business development. In Xianyu, the product publishing and editing functions are the same. This paper will take the transformation of xianyu commodity publishing and editing functions as an example to show how xianyu solves such problems.

To achieve this goal, two rounds of updates were made to publish and edit functionality. The goal of the first round is “platform and business separation, business and business isolation”; The second round will go further, aiming at “decoupling between systems and improving team synergy efficiency”.

1 Platform and service are separated, and service and service are separated

In the first round of transformation, Xianyu extracted the new application item from the original product publishing and editing functions of the old application. In order to achieve the goal of “platform and business separation, business and business isolation”, SWAK developed a set of technical framework. For details, please refer to the article “Business Code Deconstruction Tool –SWAK”, which introduced its design idea and implementation principle. With SWAK, the platform logic is separated from the business logic, and the logic between the various services (such as rental services, free delivery services) is no longer coupled, but becomes package isolation (or jar isolation, of course).

Take a look at the schematic diagram of the application after the transformation:

  • We abstracted 17 SWAK extension points from the publishing and editing backbone.

  • The backbone of publishing and editing is the orchestration of these extension points. The trunk process is written without thinking about how the business implements these extension points.

  • We implemented each of these extension points for different businesses (more accurately, TAG in SWAK).

According to this way of development, we can divide the development students into the following two roles:

  • Business developers. Business developers are primarily responsible for the code associated with each business. In the Item application, business students need to maintain their personalized business logic related to publishing and editing.

  • Backbone developers. The trunk people only need to maintain the trunk code, especially the abstraction of extension points. As different services are added, the original extension points need to be adjusted.

After SWAK transformation, the following advantages are obtained:

  • Code logic is clear, variable and immutable at a glance.

  • Code reuse becomes high.

  • Variable logic is isolated by tag, and the implementation of a single tag does not affect the implementation of other tags, reducing development and testing costs. Whether divided by “type” or by category, the corresponding development and testing students only need to focus on the corresponding logic.

  • New developers are quick to understand and easy to pick up.

2. Decoupling between systems to improve team coordination efficiency

Take renting as an example — students in renting business need to maintain a set of logic related to renting and editing in item application (such as verifying the authenticity of district data and subway data, etc.); Students in rental business also need to maintain a set of logic related to rental details in the logic of details application (such as display map, display internal facility label); Students in rental business also need to maintain a set of logic related to rental transaction (such as booking house viewing) in the transaction application logic. Students who rent houses not only need to work on their own code logic, but also need to modify the publishing and editing application item, the details application, and the transaction application…… The experience is very bad, and there is a high probability of taking on a simple business and having to modify and release four or five applications.

From the trunk, on the other hand, the developer’s perspective, its application not only by themselves or their own small team to maintain, and there are many business developer also in the application to distribute and change, and frequency could be far more than the trunk development task of release and deployment of frequency (or the trunk extension point logic smoke have bad). This is not conducive to the stability of the entire application. A business service has hung, which should only affect A business, not the trunk. Following this logic, it is best to do JVM isolation. In essence, the first transformation completes the decoupling between businesses, while the second transformation completes the decoupling between systems.

Conway’s Law tells us:

Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.

In short, it is the consistency between the personnel organization structure and the system structure. And the complete decoupling between systems is exactly in accordance with Conway’s law. This round of transformation is called “business servitization”.

  • First, we separate out the rental business. The original post and auction business is not maintained by a separate team (but there are few new requirements) so it will remain in the trunk app for the time being and will migrate out as well as the rental app when appropriate.

  • Second, the rental business provides services to the backbone application by way of remote service. An interface is an extension point provided by the trunk business. Since remote services are now preferred for connecting trunk and vertical applications, we have also made some special changes to the definition of extension points for performance and security concerns, which will be discussed later.

  • Finally, the SWAK framework makes some changes to register and invoke remote services. Compared with local services, remote services generally have problems such as timeout and abnormal connection. However, different interfaces have very different strategies for handling these exceptions, as detailed in “Targeted Improvements to the SWAK Framework” below.

In this way, we completely separate the backbone application from the business applications. Taking the rental business as an example, the rental team is responsible for developing and maintaining the independent application Rent for rental business. Rent’s personalized publishing and editing needs only require the development and deployment of the Rent app, without modifying the trunk app. The backbone application is only maintained by the students of the backbone team, and will not be developed and deployed by the students of other business teams, so the stability can be more guaranteed. Each business system is independently developed and deployed. All these greatly reduce unnecessary communication costs and improve collaborative efficiency.

Trunk applications and service applications are connected through a thin layer of interfaces that are “declarations” : Interface definitions, DO definitions, and default Reduce policy definitions for extension points.

Targeted improvements to the SWAK framework

As mentioned in the previous article “SWAK: Business Code Deconstruction Tool”, the SWAK framework registers the information required by the framework through various registery at application startup time. The most important piece of information is the name of the implementation class or instance of the business Tag and its corresponding SWAK interface. Most RPC frameworks provide a proxy on the client side, which removes a series of internal operations such as service discovery, preservation, serialization, network communication, and deserialization. In fact, SWAK supports remote service calls by registering only business tags and the corresponding relationships between client instances of these RPCS. In Xianyu, RPC uses the HSF framework used by Alitong (a similar open source framework is Dubbo), where the client of RPC is the ConsumerBean in HSF.

As mentioned above, RPC calls introduce the concepts of service timeouts and connection exceptions. Why limit timeouts? It is because the timeout of a single application cannot occupy the service resources of the main application and cause other services and the entire application system to be affected (for example, most threads block on timeout calls). There are corresponding policies for handling timeout exceptions and connection exceptions. Here, we define three exception handling policies that the SWAK framework automatically handles by setting annotations on the configuration. The three strategies are:

  • IGNORE. That is, throw an exception directly to the upper layer.

  • The SKIP. If an interface has multiple tags, the implementation of the extension point under the current tag will be skipped and the implementation of the extension point under other tags will continue.

  • DEFAULT_VALUE. Return the default value. Default values are set through spEL expressions.

2 Reduce the number of extension points

It is well known that RPC calls add a portion of network transport and serialization overhead over local calls. For a single call, adding a few ms is fine, but for 10, 20, or more calls, the overhead is significant and should be taken seriously. Therefore, how to reduce RPC overhead is a problem that must be considered.

The surest way is to reduce the number of RPCS.

In practice, we have found that many extension points are actually capturing business configuration. For example, in the idle fish business, “whether to support multiple inventory” is a configuration, such as renting does not support multiple inventory. These service configuration items are determined by the service form and will not change basically. Therefore, a set of configuration items can be packaged together and called, and can be cached or maintained directly by the trunk application. In the Case of the Item application, these configuration items relate to the common stored procedures of the trunk, which are currently maintained by business parties entrusted to the trunk developers and are currently configured in the trunk environment. Dynamic modification can be made through Ali’s dynamic configuration platform (such as Switch and Diamond).

In addition, we combine some adjacent extension points. The logic between these adjacent extension points is simple and does not interrupt the main process. We reduced the number of extension points from 17 to 6 by using the “configuration interface” and “Adjacent extension point merge” operations. Note that fewer extension points are not always better. Fewer extension points mean more “overfitting”, which may result in major changes to the trunk due to failure to adapt to subsequent business changes, so there is a balance to be struck between volume and scalability.

It’s also worth noting that SWAK makes a small change to configuration extension points and provides a visual interface to view the return value of the current configuration extension point. Developers can intuitively understand the current configuration values for each business.

3 interface object definition and detailed design

In idle fish, what kinds of business need to store the same, from the perspective of a wandering fish released interface is easy to find it, is based on the object (such as title, description, picture) add some business related data, such as auction business information such as the start date specified in the auction, free of charge in business Settings to exchange currency, set the bar code on the book business. That is to say, it is also allowed to auction a book, which gives rise to the composite business of auction business and book business superimposed together.

For trunk application developers, a single interface should be provided to support all business types so that a new interface is not required every time a business is modified or added. From a stability point of view, this is a reasonable requirement. Since it is a single interface, the definition of DO should be uniform. Take commodity DO as an example, there are three ways:

  1. The first is an inheritance structure, which is not suitable for business overlay. In addition, the trunk needs to know the DO of each business, and the trunk needs to change every time the business is modified or added.

  2. The second is the composite structure, which is suitable for the case of business stacking, but like the previous one, the trunk needs to know the DO of each business, and the trunk needs to change every time the business is modified or added.

  3. The third uses the Map type class to host the definition types of individual businesses (Biz). The trunk has no idea or need to know how the individual business DOS are put together. This approach has the best scalability (somewhat borderless scaling) and also separates trunk and business applications, coming closest to the desired separation of trunk and business. We ended up with this one.

Using the third object model, taking a new business as an example, its development process is as follows:

  1. The new business server developer and client developer agree on DOS for each business, which are stored in bizMap fields. Trunk application developers do not need to know these conventions.

  2. Trunk application adds a new service configuration, which is actually the identification information and routing information of the new service.

  3. New business applications implement backbone extension points.

  4. Joint investigation, testing and launching.

The business application sets the data to be updated in the return value of the extension point, which is merged by the trunk application. Business applications should not and cannot modify ItemDO directly to avoid affecting the processing logic of other businesses. For publishing and editing logic that requires persistent storage, it is important to control business changes to ItemDO, otherwise it is theoretically possible for businesses to change all key fields beyond recognition. In the “configuration interface” mentioned earlier, there are such configurations as whether the property field can be modified for the service, whether the description field can be modified for the service, and so on.

The commodity publishing and editing functions of Xianyu have been reformed and upgraded twice based on the SWAK framework. The first upgrade completed the decoupling between platform and business and the decoupling between business and business, and the second upgrade completed the decoupling between system and system through the use of RPC calls between platform and business. After the transformation, it can more effectively collaborate with more teams to support various businesses more quickly and stably.

The SWAK framework continues to evolve, as some extension points can in principle improve performance through parallel or asynchronous processing, but support is not yet available. In these two transformation, we also have a lot of accumulation in the test case collection, playback, monitoring alarms and other aspects, please pay attention to the public account looking forward to the subsequent article sharing.

In depth | 10 minutes to read alibaba senior expert’s share on Flutter Live2018

TensorFlow app “UI 2 Code”

Thousands of online problem playback technology revealed

2018 Double 11· Real-time selection of top goods and excellent products — “Mach”