java project architecture summary

  This year, I started to write a technical blog again, and I will write more regularly in the future, which can make my thinking clearer.
  Last year, I worked on a project for a year. To put it simply, it is a user background system, and then configures an APP and a web page; the technical points included are all-encompassing, and here we mainly talk about the system architecture. At the beginning of the project, it is similar to doing a traditional web project. According to the MVC model, a project includes the PC Web front-end page, the data model layer, the database transaction layer and the business logic layer, and another Android project is used as the App client; during the period, in order to solve the problem Concurrency, load, communication and other issues have also introduced a series of middleware such as Redis, Alibaba Cloud OSS, Netty, etc. However, the overall structure of the project has remained basically unchanged. In the early stage of the project, our two all-around warriors, the client and the server, picked them out. It was launched. With the gradual increase of project requirements and functions, the number of developers has also increased a lot. Now there are more than 10 developers.
  As the project gets bigger and more functions, the problem of architecture will follow, and each version update is an extremely cumbersome and painful process. For example, the front-end UI needs to be optimized, but the web front-end and back-end projects are all in one project. To start the project with the front-end alone, various development environments and tools must be installed. The front end is highly coupled, and the front end does not have any experience in front-end interactive development such as ajax, js, etc. According to the inability to understand and optimize the front-end, in the end, only some css and icons can be optimized by the front-end; this architecture is also not suitable for multi-person collaborative development, although There is an asynchronous code submission and merging mechanism such as svn, but there is still the problem of mutual coverage between codes, because it has not been divided into fine details before, and many functional modules may directly have a large amount of actions, facing such a huge amount of Code, the learning cost of new colleagues is also getting higher and higher; the project compilation time is getting longer and longer, it may be started in a few seconds before, and there is no problem even with hot update, and then it is basically more than 30 seconds to one Minutes, sometimes when the class web server under hot update needs to be recompiled, it is basically paralyzed; the most terrible thing is the cost of updating and maintaining the code. If the code is updated and tested, it can be safely lost on the server. , Now even if it is a small change, without going through the intranet, public network, and batch testing of prototypes for 2-3 rounds, the update is uploaded and I can't sleep well; the cost of publishing the update is more, and the APP client is not As I said, dozens of APP compiled and even the computer have been replaced with server configuration. Every time a version is updated on the server, I dare not move it during the day. If there is any update problem, WeChat, QQ and phone are basically like war. , so every time you stay up until midnight to release the update, and it is common for updates to be released until the early morning; then there is the problem of branch deployment, each time you add an independent server, sometimes it may be just a different database, but the basic All middleware and projects must be deployed once, and the update version is the same, and the update has to be tested one by one.
  Having said so much, the architecture is still not scientific enough, but it was a very good technical architecture in the early days, but with the development of the Internet, it is becoming more and more inapplicable. There are two reasons, one is that the coupling degree of the architecture project is too high, and the other is that the design method of the architecture is oriented towards functional modules rather than oriented services. By splitting the project, such as splitting the web front-end into a separate project, so that the front-end can focus on page development, and there is no need to install the development environment and tools related to the back-end, and the interaction with the back-end can completely pass through the pre-defined service interface. Develop; design the database transaction layer and business logic layer as interfaces, and split them into an independent interface service project; use it to interact with the web front-end and back-end services; split the back-end service implementation into independent projects for Implement data transaction layer and business logic layer. The front-end H5 page used for mobile phone and WeChat browsing is split into independent projects; in this way, with the addition of the mobile APP, the original 2 projects are split into 5 projects, the coupling between each other is greatly reduced, code maintenance and Publishing costs are reduced a lot.
  After the project is split, it is actually equivalent to turning the original independent vertical project into a distributed project. We generally use the SOA service-oriented design method to make calls between different projects, such as early enterprise-level EBS companies. Bus, a bus is responsible for scheduling different project services. Some service frameworks I have learned so far include Ali's dubbo framework, Spring cloud, etc. Among them, dubbo is a service framework based on java Rpc remote call and zookeeper registration service center. You can see As one of the branch points of Spring cloud, through these service frameworks, you can call each other in projects in these different processes, whether it is code reuse or update and maintenance costs, it is much more convenient. For example, we are now doing a new one. In the project, many functional codes are basically the same and can be reused completely. According to the existing architecture, the method is to copy the code to a new project, and then to update and maintain this part of the code, it must be operated in two projects; After the service architecture, it is also very convenient to locate the follow-up problems and expand the branch nodes. For example, if the service implementation layer is found to be overloaded, only the machine deployment service implementation project is added instead of the whole deployment. For some differentiated branch node deployment and Maintenance is also very convenient. The most convenient thing is that everyone can develop independently of each other in the future, because everyone is facing a service interface, and does not need to care about the specific implementation behind the interface. The development can be completed by putting a test sample data in advance, and the subsequent service implementation is completed. You can replace it, and you don't have to worry about mutual influence when you release an update. What you update will only affect the current function.
  At present, we should have basic architectural ideas, and we have also made some demos of service frameworks, such as dubbo, but in order to pursue the progress and stability of project development, we may still use the original architecture for development in the short term. Although many shortcomings have been mentioned, But more is actually troublesome and cumbersome. There is still no problem with stability and maturity. The reason why modern technology is changing with each passing day, in addition to functional innovation and performance optimization, is also very important to solve the problems of us developers in the development process. Various inconvenient and unreasonable problems encountered in