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

一：概述

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

二：基础篇

提出以下4个问题

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

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

什么是微服务？
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. 如何有效的组织这些服务，哪儿些服务需要被一起水平扩容，这些问题会对服务的扩容后带来不必要的麻烦
微服务的诞生背景
1. 微服务的概念其实早就有之，但是是互联网时代的蓬勃发展造就了他的成熟
2. 互联网时代的产品通常有两大特点
  1. 需求变化快，那么如何从系统架构出发，构建灵活，易扩展的系统，快速应对需求的变化
  2. 用户群体庞大，如何保证系统的可伸缩性，高可用姓，成为系统架构面临的巨大挑战
3. 过去十年间，敏捷，精益，持续交付等价值观和方法论的提出以及实践，让很多组织意识到应对市场变化，提高向应力的重要性
4. 单块架构系统已经无法应对快速发展的
微服务和SOA之间的区别
1. 微服务更灵活，可实现已经可扩展性更好，强调的是一种独立测试，独立开发，独立部署，独立运行的软件架构模式
2. 微服务是SOA的一个子集，对于其实现方式来说，他是一种更加符合现代化互联网发展趋势的实践，是一种更容易帮助企业或者组织有效并且成功实施服务架构的实践
为服务的本质，从以下几个方面来概括
1. 服务作为组件
2. 围绕业务组建团队
3. 关注产品而非项目
4. 技术多样性
5. 业务数据独立
6. 基础设施自动化
7. 演进式架构

秒客网

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

相关文章