系统架构演变

集中式架构

• 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本。此时，用于简
  化增删改查工作量的数据访问框架(ORM)是影响项目开发的关键。
  
• 存在问题：
  • 代码耦合，开发维护困难
  • 无法针对不同木块进行针对性优化
  • 无法水平扩展
  • 单点容错率低，并发能力差

垂直架构

• 当访问量逐渐增大，单一应用无法满足需求，此时为了应对更高的并发和业务需求，我们根据业务功能
  对系统进行拆分
  
• 优点
  • 系统拆分实现了流量分担，解决了并发问题
  • 可以针对不同模块进行优化
  • 方便水平扩展，负载均衡，容错率提高
• 缺点
  • 系统间相互独立，会有很多重复开发工作，影响开发效率

分布式服务

• 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求。此时，用于提高业务复用及整合的分布式调用是关键。
  
• 优点
  • 将基础服务进行了抽取，系统间相互调用，提高了代码复用和开发效率
• 缺点
  • 系统统间耦合度变高，调用关系错综复杂，难以维护

微服务

• 目前的微服务并没有一个统一的标准，一般是以业务来划分将传统的一站式应用，拆分成一个个的服务，彻底去耦合，一个微服务就是单功能业务，只做一件事。

微服务与微服务架构

• 微服务是一种架构模式或者一种架构风格，提倡将单一应用程序划分成一组小的服务独立部署，服务之
  间相互配合、相互协调，每个服务运行于自己的进程中。
  服务与服务间采用轻量级通讯，如HTTP的RESTful API等
  避免统一的、集中式的服务管理机制
• 优点
  • 每个服务足够内聚，足够小，比较容易聚焦
  • 开发简单且效率高，一个服务只做一件事情
  • 开发团队小，一般2-5人足以（当然按实际为准）
  • 微服务是松耦合的，无论开发还是部署都可以独立完成
  • 微服务能用不同的语言开发
  • 易于和第三方集成，微服务允许容易且灵活的自动集成部署（持续集成工具有
    Jenkins,Hudson,bamboo等）
  • 微服务易于被开发人员理解，修改和维护，这样可以使小团队更加关注自己的工作成果，而无需一定要通过合作才能体现价值
  • 微服务允许你融合最新的技术
  • 微服务只是业务逻辑的代码，不会和HTML,CSS或其他界面组件融合。
  • 每个微服务都可以有自己的存储能力，数据库可自有也可以统一，十分灵活。
• 缺点
  • 开发人员要处理分布式系统的复杂性
  • 多服务运维难度，随着服务的增加，运维的压力也会增大
  • 依赖系统部署
  • 服务间通讯的成本
  • 数据的一致性
  • 系统集成测试
  • 性能监控的难度