运维基础基础为零，高可用架构如何设计？

Gray1982

      在一些中小公司常遇到这样的问题，运维基础几乎为零。虽然网站使用的是常用开源软件nginx apache redis mongodb php-fpm tomcat mysql oracle;一些大数据方面的话可能还需要hadoop zk kafak 等常用软件。但大多是开发来部署使用，N个应用放在同一台服务器、单点、配置文件写IP、各应用监听为0.0.0.0等等不符合运维规范标准的情况，这个时候我们需要做的就是先了解业务再提出相关改进。

话题讨论：
1.可以根据并不限于上面的情况来设计一下高可用的网站及大数据方面的架构。
2.架构也不仅仅限于业务逻辑，也可以大概设计一下IDC方面的高可用架构。

注：以上架构设计限于200台服务器内（比如常用的架构如第一层负载、第二层页面级缓存、第三WEB应用、最后面的数据库）

讨论时间:
2015-7-8至2015-8-3

活动奖励：
活动结束后将选取4名讨论精彩的童鞋，赠送2015中国系统架构师大会纪念礼品一份。

奖品简介：
小米自拍神器1名


2015 SACC晴雨伞1名



中国系统架构师大会文化衫1件


鼓励奖：股市这么low，没有什么比送牛章更贴心的礼品了（凡参与本次话题讨论，均有机会获牛章一枚）


SACC 2015大会，六月6.5折抢票倒计时！

     一年一度的中国系统架构师大会震撼来袭了！SACC2015将于10月22日-24日在北京新云南皇冠假日酒店盛大召开，届时大会将云集来自五湖四海的2500名IT同胞们。
     从2009年到现在，我们伴随着中国系统架构师大会走过了七个春秋，从最早的500人规模逐年升级到现在的2500人规模，这些年我们目睹了整个IT架构的变迁史，也见证了中国IT圈内一波又一波的架构师成长之路。当天真遇到现实，会发生哪些趣闻轶事？当架构师遇到互联网+，又会擦出怎样的火花？2015中国系统架构师大会以“互联网+重塑IT架构”为主题，站在互联网+的风口上，诚邀百余名演讲嘉宾，打造一场架构师腾飞的技术盛会。


报名官网：http://sacc.it168.com/index.html

bbzsxjj

我来开个头：
首先，我建议现在的公司，特别是创业公司，运维介入越早，后期的运维工作越好开展，我们以本活动所描述为例，目前大概有200台服务器，其中已经用到了nginx/redis/mysql/mongodb/hadoop等开源软件，但是由于没有规划，所有混乱放置。
1.我们首先要梳理业务层，假如我们已经梳理完毕，情况如下：
    目前的hadoop主要用于离线运算，属于非线上业务使用
    目前的开发语言有2种，前端网站用的php,后端api用的是python
    目前核心业务主要有2块，前端的web电商及后端的api接口
    目前mongodb主要用于搜索功能使用
    目前redis主要用于缓存使用
    目前数据库使用的是mysql
    目前各种应用服务器开发自己部署，上线开发自己控制
2.经过上面的梳理，大概可以了解目前的业务情况和服务器，那么我们需要做的事情主要有下面几点：
    将测试环境/离线服务/生产服务分类并进行拆分，严格控制生产环境权限，控制上线操作
    将同类开发语言开发的服务合并到同类服务器上，严禁不同开发语言应用混合在同一台服务器上运行
    规范应用部署路径/账号/端口号/权限
    数据库账号进行梳理，并限制账号连接IP及权限
    根据发布流程编写发布脚本，尽量避免开发登录生产环境操作
    统计所有业务用途及对应的负责人员及业务的逻辑依赖
    搭建监控系统对所有的生产环境业务进行监控并根据业务统计结果分类发送报警
    有服务器的情况下，尽快搭建内网DNS系统
3.梳理完业务后就可以针对性的开始本文的主旨，架构设计，我觉的需要主要有下面几点：
    严禁在生产环境出现单点问题系统（可以使用集群/HA方式消除）
    对核心业务使用集群方式增加业务处理能力（nginx的upstream/haproxy/lvs等）
    架构必须是可扩展的，实在没法扩展的，在架构设计的过程中必须考虑后期的可拆分性（比如使用域名方式）
最后，我觉的常见的web的3层结构是相对比较通用的做法：
  第一层，使用代理层（缓存层），主要看业务特点，一般可以使用haproxy|lvs这一类的软件，7层建议使用lvs，7层建议使用haproxy
  第二层, 使用nginx做应用中间层，比如：nginx+php-fpm
  第三层,中间件层，在大规模的数据访问中，一般将接口及一些公用的功能抽离出来，做成中间件层，比如：有很多大的公司数据库访问也使用中间件调用，应用不直接连接数据库操作数据，再比如：消息中间件（kafka/activemq等）
  最后就是数据库层。
  另外，在实际生产环境中更复杂一些，可能会引入cache层，比如：redis/memcached
这里只是抛砖引玉，欢迎大家探讨！
   

bbzsxjj

回复 3# bun

  理论上是这样的，相比较后期的成本，前期的投入是非常小的，不过这个东西是需要看老板的意思，我只是个建议，呵呵!
   

ohyeath

回复 4# bbzsxjj


    创业初期，一切为了积累，到了需要改造的时候，除了原有的关键数据外，其他的东西可以全部推到重来，成本，比早期请运维介入便宜多了，也更符合实际。早期，连老板自己的需要是啥都不能确定，后面肯定有大变化，既然是大变化，小打小闹的修改、调整，还不如推到重来。

Gray1982

回复 6# lanni654321


    换成haproxy或者lvs都可以，如果你那边只是四层转发的话。

Gray1982

回复 8# lanni654321


    如果7层也在用，看看haproxy吧。