系统架构与自我成长

1 自我成长

1.    工作态度转变，系统出了问题哪怕不关自己的事，也要去悄悄的分析。对于整个系统有着自己的理解和设计，优化方案。
2. 技术方面，学习比较流行的技术，结合业务去学习，更有利于自己去设计方案。 广学框架(最起码达到学的框架能应用到实战中)，否则你只知道这个框架大体干嘛的， 一定应用很有可能会踩坑。负载技术：Haproxy，DNS，nginx,LVS,F5
3. 个人魅力,技术能力，沟通能力，激情，画大饼，执行能力。等等
4. 个人任务估时，+30%时长。 或者 大家一起评估选出折中估时。

1 好的系统标准

1 维护成本低（设计差，逻辑不缜密，代码写的差，经理监督不到位  等等 都会造成维护成本高。）

2 模块设计清晰明了，代码管理规范（设计模式，解耦，等）。

3  易扩展，能容高并发（项目初期可以不负载，但是不能没有这个实现）

2 代码管理

2.1 git 上提交代码规范

git 上只能有代码，不允许有idea的文件等。。。 如果将idea的文件也提交了，因为每个人的idea文件不一样

1. 每个人配置的maven等不一样，需要修改。等等。
2. 有的很实用功能有时会用不了，例如：贮藏功能
3. 对于不会和代码的人，进行流程培训，以防污染代码
4. 生产分支严禁私人合并。

     

3 旧系统改造过度

 进入新公司不要着急改造项目

1：熟悉旧项目  

      熟悉旧项目帮助我们选择最佳合适的方案。

2：熟悉组员的能力 

      改造就意味新东西的加入，组员的技术能力怎么样？学习成本占比多少。超过20%不可。

3：熟悉未来业务方向

      增加改造时的对外来要有可扩展性。易用性，复用性 等。

方式一：新旧隔离 （我们原来的系统选择的是第二种方案，新旧系统分隔。）

老用户用老系统，新用户用新系统，数据相互隔离，待新系统完全稳定后可以做数据迁移。（也可以不迁移。就是旧项目还有运行成本的。）

方式二：一刀切

直接制定好停机时间，老系统直接关闭，历史数据迁移，直接使用新系统，一旦升级失败，处处是逻辑问题，到时候老系统停了，新系统老是问题。两难问题。

适度解决未来问题（2-3年）

1. 未来用户的规模程度。现有系统能否支撑，能否支持扩展

2. 未来技术栈的更新迭代，掌握的技术多，才能选择更好的找到解决问题的方式（大环境下裁员，提升自己的技术栈）

3. 研发团队的自身因素（稳定性，成本）

4 架构设计

4.1 nginx+tomcat

 

4.2 F5+nginx+tomcat

 

4.3 SLB+nginx+tomcat

SLB：阿里云的产品，负载均衡 ,可以搭配 阿里云ECS使用。 

为啥要SLB还要搭配nginx?

SLB性能比nginx强，它就是负载。nginx还要放静态页面等。

 

 4.4 LVS+nginx+tomcat

 和上图一样，将SLB换成LVS。 主要原因 也是 LVS性能比nginx高

4.5 云上服务器优化方式

优先访问近点地区的服务器，（华南，华北 ）--> DNS(转到对应用户的对应地区的服务器上)---nginx---tomcat