0%

拖着行李箱的人们,

满载着一年的劳累,

穿过长长的铁道,

回到母亲怀内,

妈妈

我想再睡会

2024.2.7 腊月二十八


My personal server uses CentOS 7.9, and there are often strange errors when deploying some AI applications.
For example, recently, an error was reported when deploying an application:

1
/lib64/libstdc++.so.6: version GLIBCXX_3.4.xx not found

Online search for solutions, there are different opinions, either reinstall gcc, or recompile and install libstdc++,export LD_LIBRARY_PATH and so on.
Several attempts have failed, and there is no way to upgrade the os version. Finally, a suitable solution is found, and it’s worked for me.

  1. Find and display all packages that provide libstdc++.so.6 as a library file through yum
1
sudo yum provides libstdc++.so.6
  1. Download new version libstdc.so.

NOTICE: Since I need version 3.4.22+, so I can just update it to 3.4.26. Other versions are the same.

1
2
3
cd /usr/local/lib64
sudo wget http://www.vuln.cn/wp-content/uploads/2019/08/libstdc.so_.6.0.26.zip
unzip libstdc.so_.6.0.26.zip
  1. Copy libstdc++.so.6.0.26 to /usr/lib64
1
2
cp libstdc++.so.6.0.26 /usr/lib64
cd /usr/lib64
  1. Check the soft link version of libstdc++.so.6,
1
ls -l | grep libstdc++

It may shows like this:

1
libstdc++.so.6 ->libstdc++.so.6.0.19
  1. Remove /usr/lib64 original link libstdc++.so.6, you can backup it before remove.
1
sudo rm libstdc++.so.6

then, relink it.

1
sudo ln -s libstdc++.so.6.0.26 libstdc++.so.6
  1. OK, check the newest link
1
strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

It may shows like this:

1
2
3
4
5
GLIBCXX_3.4
...
GLIBCXX_3.4.25
GLIBCXX_3.4.26
GLIBCXX_DEBUG_MESSAGE_LENGTH

Well Done!


In my Hexo blog, when I include special symbols inside the title in posts, it reports this error:

1
2
3
ERROR Process failed: _posts/en/XXX.md
YAMLException: incomplete explicit mapping pair; a key node is missed; or followed by a non-tabulated empty line at line 1, column 54:
... for Backend System Refactoring\: How to do backend system refac ...

Solution:
Include the title in single quotes, like:

1
2
3
title: 'How to read a book'
lang: en
date: 2023-01-01

coverimg

Introduction

As the company’s business experiences explosive growth, both the scale of requirements and the user base are rapidly expanding. This presents challenges to the system in terms of the three high (high performance, high concurrency, high availability), scalability, and maintainability. The old system, due to various limitations in its early design (such as the expertise of early participants, the foresight of architectural design, impatience of management, etc.), gradually becomes inadequate to meet current and future demands, exposing various issues. Developers find themselves dragging an old, worn-out car on the highway, which is a daunting task. In simpler terms, the codebase of the old system has become too problematic to fix, leading to a situation where developers either get buried in its issues or abandon the project altogether.

At this point, a common question arises: should we continue trying to patch the issues, or should we choose to refactor? Patching is simply not feasible, not in this lifetime. Refactoring, on the other hand, requires the courage of a true hero because it’s a complex and time-consuming task. Moreover, it can impact ongoing business development or even bring it to a standstill. Often, product managers and executives are not supportive because they only care about one thing: when will the next feature be ready? Everything else is your development team’s problem.

If you choose the path of refactoring, you must be prepared to see it through, no matter what. How can you ensure a successful refactoring from the get-go? Based on common practices in internet projects and my personal experience in refactoring projects, here is an outline of the common steps for refactoring systems of various sizes:

Step 0: Convincing Stakeholders

Refactoring is not just the responsibility of the development team; it’s a collective effort involving the entire project team. Refactoring can improve the system’s performance, availability, and scalability, as well as optimize and streamline business processes to meet new demands. It requires a significant investment of resources and must have the support of stakeholders. Typically, this requires explaining the benefits and drawbacks of refactoring, as well as the critical issues that would arise if refactoring is not done. Once you have their support, the refactoring work can officially begin.

Participants: Technical Leader

Step 1: Establish Clear Refactoring Goals

Refactoring is a long-term endeavor; it’s not something that can be completed in one or two iterations, or even within a few months. It requires a substantial investment of manpower, resources, time, and effort. So, what are our goals in this prolonged battle? Are we aiming to meet the system’s high-performance requirements through a more efficient architecture? Or do we want to enhance code quality through refactoring? Perhaps we aim to introduce new technologies and frameworks to upgrade the entire system or optimize business processes to address previously unmet requirements. Once you have clear goals, you can work purposefully.

Participants: Technical Leader, Architect

Step 2: Define the Scope of Refactoring and Make Predictions

Refactoring typically falls into several levels:

  • Platform-level refactoring: Refactoring the entire platform, such as Alibaba transitioning from the LAMP stack to the Java platform.
  • System-level refactoring: Refactoring specific business systems, such as introducing microservices or SOA architecture to break down monolithic applications.
  • Architecture-level refactoring: Improving the existing architecture through adjustments and redesign, addressing architectural shortcomings, like decoupling business logic through layered design or introducing caching for improved concurrency.
  • Business-level refactoring: Addressing specific business requirements that cannot be met due to the limitations of the current system, often involving the refactoring of business processes or database structures.
  • Module/code-level refactoring: The most common form of refactoring, typically involving the use of design patterns, encapsulation, and code optimization to improve code structure and performance.

Determine the level of refactoring required, the overall scope, and the technology stack for refactoring. Then, conduct a scientific assessment and estimation of the refactoring work. This includes identifying the costs, required resources, and time commitments, as well as assessing whether ongoing business requirements can be accommodated during the refactoring process. Once these predictions are established, you can provide stakeholders with a clear understanding, especially when they ask when new requirements can be delivered.

Participants: Technical Leader, Architect, Developers

Step 3: Familiarize Yourself with the Old System and Document Business Processes

Refactoring is not about abandoning the old system; it’s about continuously working with it. Knowing your enemy is the key to victory. Refactoring not only requires a clear understanding of the new system’s goals and future, but also a deep familiarity with the old system, especially its pitfalls. At this stage, the participants in the refactoring project, especially those who worked on the old system, should document and organize information related to the old system’s business and technical details. This includes collecting documents such as design documents, technical documents, architecture diagrams, UML diagrams, and ER diagrams related to the system.

The following are common preparation tasks before refactoring the old system:

  • Gathering information and documentation related to the old system, including design documents, technical documents, architectural diagrams, UML diagrams, ER diagrams, and other graphical materials.
  • Mapping and documenting business lines and processes, outlining projects and business flows, and documenting them.
  • Reviewing key code and database designs in the old system.

Any issues or uncertainties should be addressed promptly through communication with relevant personnel from the business side, ensuring that problems are resolved early in the process.

Participants: Technical Leader, Architect, Developers

Step 4: Database Refactoring

If the refactoring involves changes to the database, database refactoring is typically the first step. Many refactoring initiatives are triggered by issues related to the database. During database refactoring, the deficiencies and obstacles in the old system’s database design are addressed. This may involve redesigning tables using normalization or denormalization techniques, considering sharding or partitioning strategies, and more.

Participants: DBA, Architect

Step 5: Backend System Refactoring

Before starting the backend system refactoring, it’s essential to have design and technical documentation in place, as mentioned earlier. Once these documents are finalized through discussions and planning, the architect can proceed with system architecture design, and backend developers can begin coding. This phase is often the most time-consuming and critical part of the refactoring process. The quality of the backend architecture directly affects the success of the refactoring, the quality of the business code, and the overall refactoring quality.

Due to the extended timeline of this phase and the fact that its results may not be immediately visible, Agile development methodologies are often used. This allows for iterative development, ensuring effective planning and continuous progress. The advantages of using iterations include:

  1. Effective planning and quantification of the entire refactoring process.
  2. Visible achievements at each stage, preventing the team from getting stuck in a long refactoring process.
  3. The ability to test or observe refactored parts promptly during iterations, allowing continuous learning and improvement.

During backend system refactoring, it’s essential to have clear, quantifiable goals and standards. For example, defining the QPS (Queries Per Second) supported by various systems and business modules, the expected response times for interfaces, etc. This enables the team to focus on achieving these goals during refactoring.

Regular code reviews should also be conducted throughout the refactoring process to identify and address issues with the refactoring itself and the quality of the code. This helps prevent the introduction of poor designs or subpar code that could harm the entire system.

Participants: Technical Leader, Architect, Developers

Step 6: Data Migration and Verification

If database refactoring is part of the project, data migration becomes a crucial step. It generally involves two types of migration: full migration and incremental migration. Full migration transfers all data from the old system to the new one in one go, while incremental migration handles data created in the old system after full migration until the old system is retired. These migrations are typically scripted or programmed to avoid manual errors.

After migration, it’s essential to compare the data between the old and new systems. This comparison can also be automated through scripts or programs to identify discrepancies and perform any necessary adjustments or investigations.

Participants: DBA, Developers

Step 7: System Validation, Integration, and Testing

As the backend system refactoring progresses, scripts and programs should be developed to validate the business interfaces between the old and new systems. This ensures that issues in the refactoring process are detected promptly, and, if necessary, architectural and database adjustments can be made. Additionally, increasing unit test coverage during refactoring is highly beneficial.

Once the dependencies between systems and modules are resolved, integration testing can begin. Comprehensive testing, including functional testing, stability testing, performance testing, local testing, and simulating production environments, should be performed. Any issues identified during testing should be addressed, verified, and fixed to meet the standards required for a smooth release.

Participants: Architect, Developers, Testers

Step 8: Gradual Deployment and Monitoring

When the backend system refactoring reaches a certain level of stability, it’s time to initiate gradual deployment. During this phase, only a portion of the traffic is directed to the new system. This allows for real-time tracking and analysis of logs and monitoring alarms. Any issues or anomalies can be addressed promptly. As confidence in the new system’s stability grows, the scope and volume of the deployment can be gradually increased. Continuous monitoring of logs and alarms should be maintained throughout this phase.

Participants: DevOps Team, Testers, Developers

Step 9: System Transition

When it comes to transitioning to the new system, it’s crucial to have a well-defined transition plan in place. This plan should include detailed processes, workflows, and contingency plans, including rollback procedures in case unexpected issues arise. This step ensures that the transition is smooth and minimizes disruption to the business.

Participants: DevOps Team, Testers

Conclusion

After completing the above steps, the system has undergone successful refactoring. However, it’s essential to understand that refactoring is a substantial undertaking, and even after the process, the system may not be flawless. Refactoring is not the endpoint but rather a new beginning.

里面,

取号,
排队,
叫号,
付费。

一切为了活着。


外面,

工作,
生活,
享乐,
受罪。

活着为了一切。

早高峰的洪流中,
我被人群簇拥着,
仿佛生命之王。

我感觉自己,
活着。
但又感觉,
死了。

ChatGPT辅助创作


There are multiple Git libraries are used on my machine, such as GitHub/Company Private Git repo, etc., the Git tool mainly uses Terminal and GitKraken, and occasionally strange issues will arise. For example, the following error occurred when deploying the Hexo Blog a few days ago:

1
2
3
4
5
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

The usual solution is to regenerate the SSH Key of GitHub.

But there’s no issue with my local configuration, I can push code normally in Terminal and GitKraken.

Guessing that there might be some hitch in the process, I used:

1
ssh -T git@github.com

And saw:

1
Hi {username}! You've successfully authenticated, but GitHub does not provide shell access.

Then redeployed and pushed, It’s worked!

Reference:

https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey


机器上使用了多个 Git 库,比如 GitHub/公司 Git 库等,Git 工具主要使用 Terminal 和 GitKraken,偶尔会出现奇怪的问题。比如前两天在部署 Hexo Blog 时,遇到以下报错:

1
2
3
4
5
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

通常的解决方案是重新生成 GitHub 的 SSH Key。

但是我本地的配置是没问题的,可以在 Terminal 和GitKraken正常提交代码。

猜想可能是哪个环节不通,于是使用:

1
ssh -T git@github.com

看到:

1
Hi {username}! You've successfully authenticated, but GitHub does not provide shell access.

再重新部署提交,搞定!

参考:

https://docs.github.com/en/authentication/troubleshooting-ssh/error-permission-denied-publickey

任务堆积如山,
债务堆积如山,
茫茫一片看不见。

我,
堆积如山。

列车从远方,
卸下年轻人,
拉走父母妻儿,
和中老年。

他们身前,
是扬起的帆,
他们身后,
是累累的山。