A way of developing Internet project

The concept of MQ (an Internet Project development method) Preface

Now an internet age, is also a big data age. With the rapid development of the Internet, the demand for products is more and more high. Although it technology is now mature, there are a lot of people who are just beginning to contact with Internet projects but don't know how to do it. Two days ago I met an entrepreneur, and his company's technical director to understand their project structure, feel very problematic, but they have been developed for six months to solve the problem from the root is not too easy. The idea of MQ is to talk to a project team that is about to do an Internet project or just start doing it. Personal Resume

I started working at the end of 12, starting with mobile-phone development and then into Java back-end development. A chance opportunity I was involved in an Internet project, when I was just a general research and development team, following colleagues to explore how to develop Internet projects. But the project has probably been done for 3 months, and has not continued to develop for business reasons. That's when I decided to start studying what the big data is, and what is called high concurrency. At the end of 14, I quit my job and started a business with friends, our company is mainly to do mobile phone app project. That's when O2O was popular, and during that time we were exposed to a lot of entrepreneurs who had an Internet product and they found us to help them achieve their functions. It was also in this experience that I learned how to develop Internet projects. The origin of MQ thought

At last year's Aliyun technology-sharing meeting, they invited technical bosses from various internet companies to share their technical framework, and the tech director of the Little TV show said: "The Internet project must be split." MQ is intended to refer to message middleware, which is used for message data communication between services. But here it does not just mean that message communication has another layer of meaning. How to Split items

University class is the time, the teacher is talking about the project to divide the project module, and later to participate in the work we also divided the module, but after the division did not feel any special clear feeling, just feel a few more package. How to split the project is always not very clear, in the process of slowly exercise I found how to divide the project module, is directly through the DB to divide the project module. split module from database design

Suppose we are going to do a mall project, mall has three modules for order/merchandise/user. Then I will split them into three modules directly when designing the database. The table name is called: T_o_order/t_p_product/t_u_user. They are then differentiated by the prefix name of the module when designing the other tables under their modules. And do not let the business in the implementation of functions need to do database operations across modules. If there are two possible causes: 1 The design of the module is unreasonable. 2 Module data redundancy can be avoided in the form of modular calls. After the design, can achieve the effect is that all modules can be stored in different databases.

How to Split items

After we have divided the database module, the Project module division is simple. Only need to coordinate with db to divide the module on the line, that is, the t_u_ into a module, t_o_ a module, t_p_ a module. The accompanying DAO service is then placed under one module. The effect is as follows: how to communicate before the module

For the same project, it is certainly not possible to avoid calls to each other within the project's internal modules, such as a single interface, which is bound to be associated with the user and the product module. So how do we deal with it. If the product or user module is invoked directly in the order module, the high coupling of the project module can not be separated. As follows: So we add MQ modules: The interdependence between modules becomes dependent on MQ modules. The modules are not dependent on each other, but they all rely on MQ. But the principle of MQ module is this: 1 MQ module does not participate in any business processing, only makes the coordination call between modules. 2 MQ modules will have the various modules of the business scheduling class, each business class under the burst out of the method, are required to be called by other modules.

Let's look at a piece of code and learn how MQ works. This is an order of business method. method requires access to user and commodity modules, but the business is accessed through MQ modules without directly accessing the module.

@Autowired private Mquserservice Mquserservice;

    @Autowired private Mqproductservice Mqproductservice;

    @Autowired private Orderdao Orderdao; @Override public map<string, object> Createorder (String json) throws serviceexception {int productId =
        Jsonutils.getint (JSON, "ProductId", 0);
        int userId = Jsonutils.getint (JSON, "UserId", 0);

        TODO Check commodity inventory product Product = Mqproductservice.checkproductcount (productId);

        Todo Check the amount of user = Mquserservice.checkusermoney (userId);


        TODO assembly order data orders = NULL;

        TODO Create orders orderdao.createorder (order);
        map<string, object> res = new hashmap<> ();
        Res.put ("Order");
        Res.put ("Product", product);

        Res.put ("user", user);
    return res; }

Let's take a look at the Mquserservice and Mqproductservice implementations of MQ modules:

@Service public
class Mquserserviceimpl implements Mquserservice {

    @Autowired
    private UserService UserService;

    @Override public
    User checkusermoney (int userId) throws Serviceexception {return
        Userservice.checkusermoney ( userId);
    }

@Service public
class Mqproductserviceimpl implements Mqproductservice {


    @Autowired
    private Productservice Productservice;

    @Override public
    Product checkproductcount (int productId) throws Serviceexception {
        return Productservice.checkproductcount (productId);
    }

The business implementation under the MQ module only functions as a function of invocation, without specific business logic. What's the point of designing an MQ module like this?

. Through the concept of MQ we can easily reduce the coupling between modules. . Simplifies collaborative development between modules.
If a module needs to coordinate the function of B module, a module only needs to add a business interface under the module service of the B module MQ, then notify the B module to implement the interface. When you need to do a split project, just replace the MQ module with RPC.

Such a project can be in the early stage under a project, but also a good solution to the Project Module Division and coordination of the problem, and then in the latter part of the project need to do a split. Only need to adjust the MQ module can be, at this time the MQ module is the real message scheduling module. evolving from stand-alone system to cluster system

As long as we consider how to split the project at the beginning of the design, then when the project reached a single bottleneck, the split is simple, this time just want to let MQ module injection mode call other modules to RPC call can. And then add support for distributed transactions. Such a distributed cluster system is built. With regard to RPC remote invocation, you can use the Dubbo framework of Ali, and the transaction framework for distributed transactions can be used in my encapsulation.

Architecture diagram for Distributed systems:

About the Mq-demo code: The code is only as a framework to understand the demo, the demo has no actual functionality.

Original address: Https://github.com/1991wangliang/mq_demo