About JD architecture

Having worked in JD, I would like to introduce the technical teams of JD first.
The overall status of technical teams in JD is not high, as JD does not treat technology as its core competency.
The user base, page views, system scales, open-source contributions and wages of technical personnel of JD are all lagging far behind those of Taobao.
But JD is still developing. Although not on a par with Taobao, it boasts obvious advantages over other e-businesses.
In addition, many of Taobao's technologies are based on its own Alibaba Cloud systems such as the Apsara cloud service. In my opinion, JD's technical architecture is of more reference significance for small technical teams than Taobao's.
The content below is just some general introductions. For details, please download the attachment.
Overview
Seven major phases of SOA


I have to make an explanation here.
• Base Architecture
This part mainly addresses the high availability and resource utilization issues of the system.
It generally refers to the O&M work. For example, single servers were used in the early stage. Later there were HA or nginx, followed by virtualization technologies such as VMware and OpenStack. And Docker then follows. There are also some applications from the development of storage technologies.
The storage technology drives the solution of some data synchronization and backup issues. For example, based on the storage technology, the cluster MySQL can be achieved without the master/slave configuration.
The virtualization technology helps to enable the elastic cloud. Some monitoring means are utilized to monitor the virtual environment in real time and then the environment configurations are modified dynamically to maximize resource utilization.
• System architecture
This section mainly eyes scalability and performance issues.
The major technologies used are distributed scheduling frameworks, MQ middleware and RESTful architecture.
• Application software
This section mainly addresses scalability and modularity issues.
The design capability matters here. No frameworks can well solve the problem. Functions are aggregated into separate modules and systems and then provided to other modules and systems for invocation independently. Usually the department is the unit.
This will usually bring about a big problem to communication, easy to generate interdepartmental walls and thus more demanding on management skills. The requirements on various documentation and interface instructions are much higher than that in small teams.
So a cloud platform to manage APIs becomes necessary.
• Procedures and methods
Mainly the modeling methods. The most useful reference includes object-oriented, service-oriented and domain model technologies.
• Business perspective
The ultimate external interface. It is pieced together by many underlying interfaces. It basically tends toward pure businesses.
Development stage examples
 
We can simply regard the last figure as being added with distributed scheduling middleware (such as Motan) and database middleware
(cloud storage, mainly proxy-based).
Architecture implementation steps


I want to emphasize that this is an endless iteration process. Like code restructuring, the architecture is streamlined and migrated once and once again.
I hold that all architecture is a result of changes, instead of being designed at one go.
Vision
Okay. All companies share this vision for their distributed architecture:


Overall architecture principle
Simple and practical.
 

Quality requirements
 
Here there is a huge workload involving the non-function part and management.
• Supportable and testable. The baffle system may need to be introduced. In addition, the unit test coverage rate among other indicators should be added before the architecture is prepared for management testing.
• Design quality. The preliminary design review meetings should be convened. There are requirements on the documentation and code annotation coverage rates.
• Runtime quality. Many frameworks should be introduced here, such as the Shiro for security, single-point login, and Auth2.0. To achieve manageability, various management terminals will be introduced, such as the ZK-based configuration management, management of distributed call framework, and system alive monitoring.

Evolution of JD architecture


Here we can see that the architecture improvement is mainly attributed to the adoption of various new technologies.
JD's SOA architecture