【读书笔记】微服务架构与实践

标签：方式   持续交付   技术   沟通   精简   www   成本   扩容   价值   

一：概述

• 微服务实在互联网大浪潮下顺势而起的
• 微服务降低了单个问题的复杂性，但是提高了整体上运维和部署的难度

二：基础篇

• 提出以下4个问题

1. 神马是微服务
2. 微服务到底怎么发展起来的？
3. 微服务的优势在哪儿里？为什么现在大家都在谈微服务
4. 微服务有不什么不足，或者对使用微服务说有什么挑战？
5. 作为从业者的我们到底要怎么看待微服务，并且如何在实际的工作项目中使用它？

• 分别针对上面的四个问题，做出解答

1. 什么是微服务？
   1. 微服务更像是一种架构模式，不是某种具体的技术。提倡将单一的应用划分为一组小的服务，服务之间相互协调，相互配合，为用户提供最终的价值。每个服务运行在其独立的进程当中，服务与服务之间采取轻量级的通信机制互相沟通，通常是给予无状态的HTTP的RESTful API. 每个服务都围绕着具体的业务进行构建，并且能够被独立的部署到生产环境，类生产环境等。另外，应尽量避免同一的、集中式的服务管理机制，对具体的饿一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建 。
   2. 什么层次才算微服务，多微才算微？
      1. 代码行数够少？
      2. 重写的时间够短？
      3. 实际上没有一个严格的定义，只要团队内部能够寻找到一个平衡点
         1. 业务够独立，这是必须的。
         2. 团队精简，10个人左右。超过十个人考虑划分子
   3. 微服务要符合单一职责原则
      1. 参考Unix系统的设计原则，它是一个完美的案例，unix系统通过各个子命令的协同配合，通过管道，搭积木一样实现强大的功能
   4. 既然是微服务，通信方式也不能太重，是必须轻量级的通信方式才好，并且是平台无关的
      1. REST是一个不错的方案
      2. Java 的RMI和.NET Remoting也能实现通信，但是他们平台相关了，绑定了语言。做不到独立性
   5. 既然是微服务，那么也需要保证自己的开发，测试，部署，运维的独立性，与其他服务之间需要高度解耦
   6. 通常情况下，应用程序由多个服务构成，各个服务之间进程独立，高度自治的独立业务实体，物理上互不影响。可以考虑以下，如果多个服务部署在一起有什么影响？
      1. 部署新服务的时候，如果当前节点已经运行多个服务，则可能会对这些现有的服务造成影响
      2. 如何有效的组织这些服务，哪儿些服务需要被一起水平扩容，这些问题会对服务的扩容后带来不必要的麻烦
2. 微服务的诞生背景
   1. 微服务的概念其实早就有之，但是是互联网时代的蓬勃发展造就了他的成熟
   2. 互联网时代的产品通常有两大特点
      1. 需求变化快，那么如何从系统架构出发，构建灵活，易扩展的系统，快速应对需求的变化
      2. 用户群体庞大，如何保证系统的可伸缩性，高可用姓，成为系统架构面临的巨大挑战
   3. 过去十年间，敏捷，精益，持续交付等价值观和方法论的提出以及实践，让很多组织意识到应对市场变化，提高向应力的重要性
   4. 单块架构系统已经无法应对快速发展的
    容器虚拟化技术孕育而生，有效解决了微服务环境搭建，部署已经运维成本高企的问题，为微服务朝大规模应用起到了推波助澜的作用
   1. 更快速的交付和部署，一个镜像搞定一切
   2. 更轻松的迁移和扩展
   3. 更简单的管理，增量管理镜像
3. 微服务和SOA之间的区别
   1. 微服务更灵活，可实现已经可扩展性更好，强调的是一种独立测试，独立开发，独立部署，独立运行的软件架构模式
   2. 微服务是SOA的一个子集，对于其实现方式来说，他是一种更加符合现代化互联网发展趋势的实践，是一种更容易帮助企业或者组织有效并且成功实施服务架构的实践
4. 为服务的本质，从以下几个方面来概括
   1. 服务作为组件
   2. 围绕业务组建团队
   3. 关注产品而非项目
   4. 技术多样性
   5. 业务数据独立
   6. 基础设施自动化
   7. 演进式架构

【读书笔记】微服务架构与实践

标签：方式   持续交付   技术   沟通   精简   www   成本   扩容   价值   

原文地址：http://www.cnblogs.com/chnan/p/6498770.html