CreateArtTechnology / Blog
  • 配置中心
     7     2018-11-14 16:17:59

    用途定义用于应用的常用配置的集中管理。

  • 图片服务器
     12     2018-11-14 16:16:48

    用途定义图片服务器作用主要分为:
    基础功能如存储和展示等进阶功能如切图、缩放、水印等高级功能如图片分析等
    架构

  • 已使用的工具
     14     2018-11-14 16:12:09

    Nginx用于反向代理和静态资源服务器。
    Http请求通过80端口到达Nginx,并将请求转发到部署在其他端口上的博客(/blog)、图片服务(/img)、Jenkins(/jenkins)、Archiva(/archiva)等前端静态资源请求(/sf即static files,包括js、css)不使用tomcat,直接使用Nginx作为静态资源服务器,效率高且节省资源
    Tomcat作为Web应用容器使用。由于机器配置一般(2G内存),跑多个Tomcat占用资源太多,而共用一个Tomcat又会导致服务之间的发布互相影响,因此这里做了个折中配置。
    业务容器:运行了博客、图片服务器,以及后续的配置中心、监控中心等,特点是可能其中某个服务发布时要重启整个业务Tomcat辅助容器:运行了Jenkins、Archiva等开源工具,特点是部署之后几乎不会修改重启,顺带吐槽一句,Jenkins占内存可真不少,机器小于1G内存就不要想这个了
    Maven用于构建项目,更新依赖、编译、打包。Archiva作为Maven私人仓库,直接部署在辅助Tomcat上了,部署和配置完之后就感受不到存在了。Mysql基础数据库,这不用解释了。Zookeeper用于构建配置中心。mysql、redis的连接信息以及将来各个服务的登录信息都将直接保存在Zookeeper中,避免硬编码后提交到GitHub。但是必须注意Zookeeper的权限配置,否则一样要暴露配置信息。Jenkins用作发布系统,很好用的持续集成工具,业务服务都是通过Jenkins部署的。Markdown、Editor.md文本编辑器和展示工具,当前的博客文章都是通过Editor.md写的,集成了图片复制上传和截图上传,现在用起来非常方便,力推!

  • 计划使用的工具
     9     2018-11-14 12:02:31

    ECS服务器配置:
    cpu
    内存
    硬盘
    操作系统
    共享型单核虚拟cpu,也就是服务器cpu其中一个核给你用
    ......

  • CreateArtTechnology再次进化
     15     2018-09-22 02:53:18

    引C.A.T已经建站好几年时间了,从Php到Java,从纯手撸到Spring Struts Hibernate,再到Spring SpringMVC Mybatis,进化过程可谓是从无到有,但随着自己工作经验丰富,越发觉得这样的开发模式非常难以管理,非常影响效率。
    Php开发时期的历程纯手撸代码,无任何框架,前后端耦合,数据库直连……加上本身对Php就不怎么熟悉,仅因为“对Java web开发更不了解”和“课程作业参加过Php web开发的一个模块”这样的原因才选择了Php。实际上这样的模式即使开发一个模块也非常耗时。一来开发环境糟糕过时,二来没能使用自己熟悉的开发语言和工具,很费力。Php时期的痛点:花了几个月时间,最终花了大量时间在整一些简单的功能(因为不懂,模块耦合度太高),到手一个半成品,可以说这段时间对自身能力几乎毫无提升。
    SSH开发时期的历程痛定思痛,坚决要利用好自己唯一的长处,也就是Java语言学得不错。当时SSH(Spring Struts Hibernate)这个整合框架的教程非常多,尽管没多久也算比较过时的框架了,但对于需要理解框架、解耦的新手来说仍然算得上合适的学习机会。这段时间,开发效率有了质的提升:一方面Java语言熟悉,学习较快;另一方面框架本身就是非常解放生产力的,尽管当时对于很多细节并不十分了解,但能够认识到Spring、Struts、Hibernate是做什么的,一旦用上就停不下来,对于后续的框架更换做了充足的知识储备。最后整个网站已经达到可以正常使用的地步了,好像看起来和其他那些大站也没差太多嘛!(呵呵,naive)总之当时自己还挺满意的。SSH时期的痛点:配置工作仍然繁琐,Spring需要配xml文件,Struts需要配xml文件,Hibernate的注解配置更是麻烦得不行。同时,对前端工作不太了解,前端渲染用jsp,而css和js也不知道去抄抄别人的,通常一半多的时间花在各种样式调整(强迫症)。
    SSM开发时期的历程如果说上述阶段都还是学生时期自娱自乐,那么见识过真正的生产环境开发后回头再看那坨代码,这都什么玩意?二话不说拿SpringMVC换掉了Struts,Mybatis换掉了Hibernate,整个网站重构。生产环境的开发模式只需要两点,1.开发效率高;2.开发质量稳定,至少bug少好修复。SSM大量的注解配置,节省了大量的开发时间,避免了很多容易因配置产生的问题,使得开发工作可以用最快的速度完成,迅速进入下一个迭代周期。前端方面,得益于公司的代码作为模板,也算是弄清楚了前端的渲染大概是怎么一回事,使用Velocity引擎渲染的同时也拿来了AmazeUI快速完成样式开发。这个时期可以说已经把公司学习的东西用得比较顺手了,很多事不用再各处搜索自己能搞定了。SSM时期的痛点:代码环境虽然已经到了生产标准,然而整个网站的架构、迭代模式、管理策略仍然还在石器时代。说白了,整个服务器上也就跑着一个Mysql,一个Tomcat,远没达到生产环境的目标,完全就一个单人小作坊,虽然事实就是这样,但也得有点追求对吧。更详细点说,有这几个问题:
    开发容易,发版麻烦。没有自动化部署工具,每次从tomcat的manager中上传war文件,手动重启tomcat。好歹公司的发版流程我都滚瓜烂熟的,不整一个浑身难受。前后端耦合,思维切换麻烦。一个人做前后端最难受的不是写前端代码,而是在写接口时考虑前端的实现细节。我需要一个完全的身份切换,当写接口时,可以独立开发、调试,不需要管前端。没有图片服务器,所有用到的图片直接保存在webapp子目录中,如果重新部署,可能还得把图片备份,风险太高。经常有实验性的开发Demo,没有地方保存,只留在公司电脑里,很可惜。部署时服务不可用。
    未来的C.A.T鉴于上述痛点,我个人倾向于建立与公司类似的生产环境,提高开发、迭代效率,减少管理难度,降低各种风险,并且能用最简单的方式集成更多实验性的,好玩的内容,顺带见识一下更广阔的世界。
    ......