In March 2015, I left Netease BoBo and came to Beitchat with entrepreneurial feelings and expectations. It has been almost three years in a flash. In these three years, beitchat background system architecture has undergone a difficult and rewarding evolution process.

This evolution process can be roughly divided into several stages: technology platform replacement stage, servitization budding stage, servitization formation stage and servitization development stage.

I. Technology platform replacement stage

In the initial stage of Beitchat, the background system architecture was based on PHP technology platform, maintained by two PHP developers. PHP technology platform is the first choice for most companies when they start up. At the beginning of the company, the business complexity is low, the number of users is small, the core is to complete the development with the lowest cost (labor cost, time cost, technology cost and server cost).

From 2013 to the beginning of 2015, after more than three years of rapid development, the original equipment (system and personnel) based on PHP technology platform began to fail to meet the needs of the company’s business development. Then, the JAVA technology platform gradually replaced the PHP technology platform.

All things are difficult at the beginning, and the technology platform replacement work faced many difficulties at the beginning.

First of all, the company’s business is developing rapidly, and system reconfiguration and business requirement iteration are in parallel. Predecessors said: this is equivalent to changing the wheels of a high-speed sports car, the difficulty and risk can be imagined.

Second, can the new JAVA technology team do it? There is no achievement, has not been recognized by leaders, colleagues.

Thirdly, can the original PHP technical team work well together? Redesigning systems is tantamount to overturning the very thing they were responsible for.

Finally, the JAVA technology team lacks understanding of the preschool education industry, which is completely different from netease BoBo’s entertainment live streaming business, which is a brand new business field.

Faced with these difficulties, the leader formulated a technology platform replacement strategy: the new business system was developed with JAVA technology, and the old business continued to iterate on PHP technology, while gradually using JAVA technology for reconstruction and switch.

Now recall this stage of experience, fresh memories.

The new business system development problem is not big, the reconstruction work is a headache. As worrying as it is, the PHP technical team is emotional, and there have been many conflicts in the communication process. In the process of reconstruction, I don’t know how many times the problems of online business, big and small, were revealed, and how many times they were blamed for the problem of responsibility. Working overtime, pulling all-nighters and staying home on weekends ready to deal with problems are the norm. One night because of unwell leave to return in advance, found that “the day is still bright”, incredibly not used to.

Fortunately, this difficult phase persevered. By the beginning of 2016, the replacement and reconstruction of the original PHP technology platform system was basically (90%) completed. This is inseparable from the trust and tolerance of the leadership, the dedication of the JAVA technology team, and the cooperation and sacrifice of the PHP technology team. So many difficulties can finally be solved, the core point is that we all have the same goal: to develop the company as the core.

2. The nascent stage of servitization

The focus of the technology platform replacement stage is to ensure the smooth transition of system reconstruction and switching while ensuring the normal business iteration, and the extensibility and maintainability of the new system architecture have not been fully considered.

In March 2016, after the company completed the SERIES B financing, the technical architecture was faced with the risk of being unable to meet the rapid expansion of product lines and technical team size. Multiple product lines and a lot of developers working on just a few applications at the same time will inevitably lead to more and more applications. How is development coordinated, versioning managed, and risk managed? It could be a mess.

In thinking about these problems, we have entered the embryonic stage of servitization. The original architecture is shown below:



In the past, a single application system integrates many services, and multiple application systems have repeated services. Each application system invokes third-party services (such as SMS, push, and IM). The updated architecture is shown in the figure below:



This stage is mainly about the extraction of public services and reuse of business modules. For example, short messages, push messages, and uploaded pictures are extracted into a common Web application, providing a unified REST API interface. At the same time, lightweight RPC framework Hessian is introduced to realize the reuse of business modules between systems.

This architecture has two obvious problems: first, the invocation method of REST API interface is not efficient; second, it is difficult to manage the call relationship of business module Hessian after increasing. At the same time, with the expansion of product lines and team members, the problems and risks mentioned above cannot be effectively solved.

3. The formation stage of servitization

In May 2016, It introduced Alibaba’s Dubbo distributed service framework. The system business of Beitchat was decomposed and reconstructed in an all-round way. By the end of 2016, the distributed service-oriented architecture of Beitchat was basically formed. The architecture is shown below:



In this stage, Disconf (Baidu) and Elastice-Job (Dangdang), a distributed task scheduling system, were introduced. At this point, we can better solve the problems caused by the expansion of product lines and team members. Flexibility in addition and composition of business service components can solve the problem of increasing product lines; The addition of team members is needed to maintain a large number of business service components. At the same time, the interface invocation method based on DUBBO protocol is much more efficient than HTTP API method.

At this point, the servitization architecture is basically formed, but there are also two obvious problems: first, the boundary of service components is not clear, and there are mutual calls between service components; The second is the lack of abnormal link monitoring mechanism.

Iv. Development stage of servitization

At the beginning of 2017, the problem of servitization component partitioning and design was reconsidered. To avoid the problem of confusing the relationship by calling each other, servitization components are divided into two categories: base service components and business service components. At the same time, the principle of inter-component invocation is formulated: only upper-layer components are allowed to call lower-layer components to ensure one-way invocation. The architecture is shown below:



In the middle of 2017, Dianping introduced the CAT (Central Application Tracking) anomaly monitoring project, and completed the access of all Application systems in October. CAT access realizes the monitoring of abnormal stack and alarm notification, which enables many bugs to be accurately discovered and solved before user feedback, greatly improving user experience and the sense of achievement of developers.

Five, the conclusion

At the end of 2017, the entire servitization architecture finally took shape. Here we would like to thank every brother of the R & D department for their hard work! The project code in the SVN/GIT repository, both in and out of The SVN/GIT repository, has left your imprint (and a lot of holes you dug, haha). There are still many problems and difficulties waiting for us in the future. Brothers of BEitchat R&D Department don’t stop moving forward, let’s face up to the difficulties together.







Thank you for your efforts at Baychat!

Li Huan and Gao Xi (PHP brothers), Zheng Xiaobin (2nd employee of R&D Department), Lin Tianrui (4th employee of R&D Department), Li Xingguang (5th employee of R&D Department), Li Haiwen, Ma Ling, LAN Guodong, Jiang Daxian, Cheng Jianyu, Li Zhifeng, Ke Fuxiang, Qiu Jun, Lin Songmian