架构选型设计方法论

概述

       技术发展至今，借助于网络的知识快速扩散，架构设计其实已经套路。中国的互联网创业兴盛，各类商业模式层出不穷，伴随着商业技术也快速发展，将各类架构模型演绎了遍，你觉得陌生无解的技术难题，在各类技术博客或者代码托管站点一搜索就有可能找到惊喜。虽然站在巨人的肩膀上可以看的更远，但是架构的基础套路还有有理由归纳分析一下，毕竟做拿来党也有碰壁的时候，这时候就需要自己用实力说话了。

套路开始

1. 成本核算，对服务清单按照优先级分配资金比例。
2. 按照服务类型以及资金量购买相应硬件，后面的公式为大概计算，真实部署时服务器最高性能只会低于计算结果：一个线程时间片负荷数量Q=800毫秒/单次业务耗时(单位毫秒)；一个线程时间片内占用带宽BW(byte)=Q*单次请求最大数据量(byte);通常系统会设定单例服务器的一秒内的目标响应数量TQ，带宽可以扩展，而cpu核心则固定，所以TQ/Q*BW=目标带宽量。并发下一个线程占用一个核心，如果超过单台服务器核心数据很明显则需要集群扩展。
3. 计算型或者IO型的业务在单次时间片内的耗时较长，对集群的数量会有要求，并且对单台服务器的多核并发要求高。
4. 类似心跳探测或者代理模式的业务，耗时较短，在编程模型上可以倾向于单线程队列处理，此类业务可以选择核心数目少的服务器。
5. 并发式系统，前端业务扩容很容易，瓶颈核心在在于数据源承载扩展。通常模式下，关系型数据库的读扩展可以通过只读数据集群扩展，写扩展则只能通过依赖分库分表减轻荷载瓶颈。而nosql数据库作为数据加速层，需要搭建一个封闭型的集群对外提供服务，绝对不能将集群中的服务单例发布出去，否则高可用就存在问题了。
6. 系统对外的路由则最好硬件承载，系统中子系统集群的负载均衡可以通过软件进行路由，当然还可以通过在远程配置化实时更新配置进行软路由。单例型的服务，如果资金容许，能避免则避免，同时，最好还要有内嵌系统的服务健康监控与计算资源调控系统，保证随时的计算资源扩容与缩减。但是这种模式需要服务调用端在开发功能上有所支持，否则会在调用端出现服务中断的情况。
7. 功能系统在设计时需要考虑目标硬件架构的多样性，多线程的架构在单核服务器上，上下文切换的消耗大于业务处理的消耗，而单线程的架构用在多核服务器上则是明显的硬件浪费，所以对于部署实例如果能嵌入硬件扫描功能最好，否则最好有硬件信息配置的功能。
8. 面向终端用户的长链接，在移动网络的移动IP技术支持下，可以忽略客户端IP变化，但是存在较大的通信成本，网络延迟要超出固网，所以服务端的容量计算需要考虑网络数据延迟在庞大数据量下的累积效应。
9. 服务划分的粒度与服务资源投入回收需要衡量，服务在总目标响应性能指标下所需要的服务器成本投入和产出需要保证不能超出总投入成本，可以容许某服务产出不足，但是必须保证总体的成本控制。
10. 开源软件选型成本第一，包括部署成本、运维成本、二次开发成本、商业授权成本。功能、性能、稳定性，则是第二需要考虑的要素。很多公司认为开源==免费，那只是对方律师没发现你或者回报太少懒的找你而已。
11. 开源软件的性能与功能通常能够满足需求，但是一般也会有伴随着的现有体系的日志、健康监控接入二次开发的工作，而对于那些用户基数大的公司，功能可能满足，但是性能也许会差很多，那么就会有熟悉某开源框架源码的开发人员的需求产生给了hr。其实这里是有个问题的，就是这类公司等于自己花钱给开源软件做了性能优化，虽然可能会有特异性需求的问题，但是也是针对某一类型的业务模型进行了优化，(某些开源授权协议下的开源软件开发方其实要求将优化公布的)。所以有时候做一些深入化的开源二次开发等于给别人培养人才，尤其是当这类工作成为一个长期状态时。