Shulou(Shulou.com)06/03 Report--

This article focuses on "how to master the framework components", interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn how to master the framework components.

Why not recommend self-research at an early stage?

The number of early R & D personnel is small, the company is not sure how far it can go, the business is relatively simple, and the business takes "fast iteration" as the highest priority. At this time, the "familiar technology" is generally selected as the selection:

Research and development language: PHP for familiar PHP and Java for familiar Java

Database: MySQL for mature MySQL and SQL-server for ripe SQL-server

Framework components: ROR for ripe Ruby on Rails, ThinkPHP for ripe ThinkPHP, and Spring boot for ripe

...

At this time, do not worry about the selection, choose what you are familiar with, the business to fast iteration as the top priority, the company has to survive first.

By the way, there are certain requirements for the technical vision of technology partners at this time. If the early direction is wrong, if the company develops for several years, the amount of data and concurrency will increase many times, and the cost and future technical response may be troublesome.

58.com 's early selection is the Microsoft technology system, and then the amount of data increases, the concurrent amount increases, and there are more and more machine databases, which can not bear the performance and the cost (can you guess how much is a SQL-server licence a year?). Later, CTO led us to transform the open source camp, although it took 1-2 years, but in the long run, it was definitely the right decision.

Now, if you start a business again, choose cloud, LAMP or Spring, you probably won't take too many detours.

As the scale expands, why control the technology stack?

As the business becomes more complex and there are more and more developers, this will happen if each leader chooses a framework that it is good at:

Site framework, team A uses SSH,team B and Spring+SpringMVC+Mybatis

Service framework, team C uses REST,team D, dubbo,team E uses thrift

Database access, team X uses mybatis,team Y, DAO,team Z uses jdbc

...

As a whole, cross-departmental transfer is becoming more and more troublesome, more and more wheels are rebuilt, technical efficiency will gradually decrease, and the cost of R & D + testing + operation and maintenance is getting higher and higher.

The first point of view: even if you do not self-research, please try to unify the technology stack.

Unified technology stack, why suggest a shallow layer of packaging?

After unifying the technology stack, redis official Java client Jedis may have such interfaces if it is not encapsulated:

String Memcache::get (String key) String Memcache::set (String key, String value) String Memcache::del (String key)

With a shallow layer of packaging, it will look like this:

String 58DaojiaKV::get (String key) {String result = Memcache::get (key); return result;} String 58DaojiaKV::set (String key, String value) {String result = Memcache::set (key, value); return result;} String 58DaojiaKV::del (String key) {String result = Memcache::del (key); return result;}

What's the advantage of this?

(1) for upstream masking the details of the underlying implementation, the caller does not care about whether the cache is memcache or redis, but only 58DaojiaKV.

(2) when the underlying layer changes, it is transparent to the upstream. When memcache cannot meet the requirements, and when you want to switch to redis, all callers do not need to change greatly. Just upgrade a latest 58DaojiaKV. The interface of 58DaojiaKV remains unchanged, and the implementation becomes:

String 58DaojiaKV::get (String key) {String result = Jedis::get (key); return result;} String 58DaojiaKV::set (String key, String value) {String result = Jedis::set (key, value); return result;} String 58DaojiaKV::del (String key) {String result = Jedis::del (key); return result;}

(3) to uniformly implement some common features, there is no need for every upstream upgrade. For example, to implement a cache access time statistics feature, all callers do not need to change significantly, and you can upgrade a new 58DaojiaKV:

String 58DaojiaKV::get (String key) {Long startTime = now (); String result = Jedis::get (key); Long endTime = now (); reportKVTime (startTime- endTime); return result;} String 58DaojiaKV::set (String key, String value) {Long startTime = now (); String result = Jedis::set (key, value); Long endTime = now () ReportKVTime (startTime- endTime); return result;} String 58DaojiaKV::del (String key) {Long startTime = now (); String result = Jedis::del (key); Long endTime = now (); reportKVTime (startTime- endTime); return result;}

Similarly, if you want to achieve a unified alarm, call chain tracking, and SQL execution time, you can use a similar approach.

The second point of view: third-party libraries should not only be unified, but also can be shallowly encapsulated to reserve future expansibility.

With the further expansion of the scale, why do we need to build some wheels properly?

With the further development of the business and the further expansion of the R & D team, although a unified technology stack is used, the pain points of different R & D teams are very similar:

There are sites, monitoring service availability, processing time monitoring requirements

There is a need for alarm

There are requirements for automatic release and automatic operation and maintenance.

There is service governance and service automatic discovery requirements.

There are call chain tracking requirements

There are SQL monitoring requirements.

There are requirements for data collection and visualization at the system level.

...

At this point, the open source framework may not meet the requirements:

The open source framework / component is too heavy, what we need may be a lightweight framework / component

Open source frameworks / components can only meet part of our needs

If you don't understand the design concept of open source framework / components, the cost of secondary development is higher (students maintaining dubboX, students maintaining database middleware Atlas can come out and say a few words)

Some common requirements are closely integrated with the business, and open source frameworks / components may not be able to meet them.

...

At this time, if the technical strength is available, we can uniformly develop some frameworks and components to solve the common pain points of all technical teams and meet the common needs of all technical teams.

The third point: build some wheels properly.

At this point, I believe you have a deeper understanding of "how to master framework components". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.