互联网应用开发 一些相关知识整理

电商行业的一些常见模式：

• B2C：商家对个人，如：亚马逊、当当等
• C2C平台：个人对个人，如：咸鱼、拍拍网、ebay
• B2B平台：商家对商家，如：阿里巴巴、八方资源网等
• O2O：线上和线下结合，如：饿了么、电影票、团购等
• P2P：在线金融，贷款，如：网贷之家、人人聚财等。
• B2C平台：天猫、京东、一号店等

一些专业术语

• SaaS：软件即服务

• SOA：面向服务

• RPC：远程过程调用

• RMI：远程方法调用

• PV：(page view)，即页面浏览量；
  用户每1次对网站中的每个网页访问均被记录1次。用户对同一页面的多次访问，访问量累计

• UV：(unique visitor)，独立访客
  指访问某个站点或点击某条新闻的不同IP地址的人数。在同一天内，uv只记录第一次进入网站的具有独立IP的访问者，在同一天内再次访问该网站则不计数。

• PV与带宽：

  • 计算带宽大小需要关注两个指标：峰值流量和页面的平均大小。
  • 计算公式是：网站带宽= ( PV * 平均页面大小（单位MB）* 8 )/统计时间（换算到秒）
  • 为什么要乘以8？
    • 网站大小为单位是字节(Byte)，而计算带宽的单位是bit，1Byte=8bit
  • 这个计算的是平均带宽，高峰期还需要扩大一定倍数

• PV、QPS、并发

  • QPS：每秒处理的请求数量。8000/s

  • 比如你的程序处理一个请求平均需要0.1S，那么1秒就可以处理10个请求。QPS自然就是10，多线程情况下，这个数字可能就会有所增加。

  • 由PV和QPS如何需要部署的服务器数量？

    • 根据二八原则，80%的请求集中在20%的时间来计算峰值压力：
    • （每日PV * 80%） / （3600s * 24 * 20%） * 每个页面的请求数 = 每个页面每秒的请求数量

  • 然后除以服务器的QPS值，即可计算得出需要部署的服务器数量

项目开发流程

公司现状

传统项目

各种企业里面用的管理系统（

• OA 办公自动化

• ERP 企业资源计划

• CRM 客户资源管理

• CMS 内容管理系统…）

• 需求方：公司、企业内部

• 盈利模式：项目本身卖钱

• 技术侧重点：业务功能

特点

• 用户不会太多
• 对用户体验要求不太高
• 对数据的一致要求高

互联网项目

门户网站、电商网站：baidu.com、qq.com、taobao.com、jd.com …

• 需求方：广大用户群体
• 盈利模式：虚拟币、增值服务、广告收益…
• 技术侧重点：网站性能、业务功能

特点

• 用户量特别大
• 对用户体验要求高

带来的问题：

• 技术范围广
• 技术新
• 高并发（分布式、静态化技术、缓存技术、异步并发、池化、队列）
• 高可用（集群、负载均衡、限流、降级、熔断）
• 数据量大
• 业务复杂
• 数据安全
• 高性能

微服务和单体应用的区别

单体应用 一个项目打包部署到一个服务器
缺点

• 项目越来越复杂，代码量越来越大
• 项目技术更新比较难
• 服务器不能水平扩展
• 项目的启动和部署比较困难
• 系统的可用性不高，出现bug服务器崩溃
• 系统的性能比较低

微服务：将项目分割成一个个小项目，每个项目单独打包部署到自己的服务器，每个服务之间可以相互调用

优点：

• 松耦合，聚焦单一业务功能，无关开发语言，团队规模降低
• 每个项目的代码量降低，容易维护
• 项目的技术更新迭代方便
• 方便系统的水平扩展
• 系统的并发量提高
• 系统的可用性提高
• 系统的性能提高

缺点：

• 系统整体的复杂性大大提高
• 系统开发和部署成本提高
• 系统运维困难

什么是微服务？

单个轻量级服务一般为一个单独微服务，微服务讲究的是 专注某个功能的实现，比如登录系统只
专注于用户登录方面功能的实现，讲究的是职责单一，开箱即用，可以独立运行。微服务架构系统
是一个分布式的系统，按照业务进行划分服务单元模块，解决单个系统的不足，满足越来越复杂的
业务需求。

比如你去医院：你的牙齿不舒服，那么你就去牙科。你的头疼，那么你就去脑科。一个个的科室，就是
一个微服务，一个功能就是一个服务。

常见微服务技术栈

服务开发 SpringBoot、Spring、SpringMVC
服务配置与管理 Netfix公司的Archaius、阿里的Dlamond等
服务注册与发现 Eurka、Consul、Zookeeper等
服务调用 Rest（服务通信）、RPC（Dubbo）、GRpc
服务熔断器 Hystrix、Envoy等
负载均衡 Nginx、Ribbon等
服务接口调用（客户端简化工具） Fegin等
消息队列 Kafka、RabbitMQ、ActiveMQ等
服务配置中心管理 SpringCloudConfig、Chef等
服务路由（API网关） Zuul等
服务监控 Zabbix，Nagios，Metrics，Spectator等
全链路追踪 Zipkin，Brave，Dapper等
服务部署 Docker，OpenStack，Kubernetes等
数据流操作开发包 SpringCloud Stream（封装与Redis，Rabbit，kafka等发送接
收消息）
事件消息总线 Spring Cloud Bus