微服务架构(初探)

微服务架构(一)

WHY？

服务拆解，每个服务拆解成之做自己的业务事物，形成高度内聚的自治性。
2.0+采用模块化的分层式架构，所有的业务逻辑代码最终会打进一个代码库中统一部署。
目前遇到的问题
1、全部开发人员会共享一个代码库，不同模块的边界模糊，实现高内聚、松耦合极其困难。（我们现在发版经常遇到要选择部分功能上线 GIT分支合并上传就会很麻烦）
2、处理遗留系统，尝试去做重构改进时，会动一发而牵全身。
3、模块的边界轻易被穿透。

微服务的主要特性

微服务架构强调每个服务一个进程。
独立开发与演进,隔离代码库至少让同一应用系统不同层次的开发人员享有自己完全自治的领地，每个微服务都有一个掌控者。
通过分解巨大单体式应用为多个服务方法解决了复杂性问题。
在功能不变的情况下，应用被分解为多个可管理的分支或服务。
微服务架构模式是每个微服务独立的部署。
开发者不再需要协调其它服务部署对本服务的影响。
这种改变可以加快部署速度。UI 团队可以采用 AB 测试，快速的部署变化。
微服务架构模式使得持续化部署成为可能。
你可以根据每个服务的规模来部署满足需求的规模。甚至于，你可以使用更适合于服务资源需求的硬件。
微服务架构模式使得每个服务独立扩展。

成本

把 1 个应用进程部署到 1 台主机，部署复杂度是 1 x 1 = 1，我们有 200 台主机，那么部署复杂度是 1 x 200 = 200。
把 1 个应用进程拆分成了 50 个微服务进程，则部署复杂度变成了 50 x 200 = 10000。
部署变得复杂和麻烦多了，同时监控的进程数也大幅增加，监控的复杂度也上升了很多。
所以实施微服务架构是有很高成本的，只有系统的规模到了一定程度才适合。
微服务推崇一切自动化的文化，这也是因为其运维复杂度的乘数级飙升，
从开发之后的构建、测试、部署都需要一个高度自动化的环境来支撑才能有效降低边际成本。

优点

每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。
微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。
微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。
微服务能使用不同的语言开发。
微服务允许容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins, bamboo 。
一个团队的新成员能够更快投入生产。
微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。
微服务允许你利用融合最新技术。
微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。
微服务能够即时被要求扩展。
微服务能部署中低端配置的服务器上。
易于和第三方集成。
每个微服务都有自己的存储能力，可以有自己的数据库。也可以有统一数据库。

缺点

微服务架构可能带来过多的操作。
需要DevOps技巧 (http://en.wikipedia.org/wiki/DevOps).

1. 开发（软件工程）、技术运营和质量保障（QA）三者的交集。
2. 是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到：为了按时交付软件产品和服务，开发和运营工作必须紧密合作。[1]

可能双倍的努力。
分布式系统可能复杂难以管理。
因为分布部署跟踪问题难。
当服务数量增加，管理复杂性增加。

实施要点

1.自动化文化与环境：自动构建、自动测试、自动部署。
2.围绕业务能力建模服务，松耦合、高内聚、暴露接口而隐藏实现细节。
3.服务协作模型：中心化（乐队模型：中心指挥）和去中心化（舞蹈模型：群舞自组织），各自场景不同。
4.服务交互方式：RPC/REST/WS 技术很多但考虑统一。
5.服务部署的独立性、失败隔离性、可监控性。
6.服务流控：降级、限流
7.服务恢复：多考虑故障发生如何快速恢复而非如何避免发生故障。
8.服务发布：灰度。
9.服务部署：一服务一主机模型，需要虚拟化(Hypervisor)、容器化(LXC, Docker)等技术支持，实现硬件资源隔离。
10.服务配置：中心化配置服务支持
11.康威定律：任何设计系统的组织，最终产生的设计等同于组织之内、之间的沟通结构。系统架构的设计符合组织沟通结构取得的收益最大。
12.伯斯塔尔法则：服务健壮性原则 —— 发送时要保守，接收时要开放。

网关

实现一个API网关作为所有客户端的唯一入口。API网关有两种方式来处理请求。有些请求被简单地代理/路由到合适的服务上，其他的请求被转给到一组服务。

相比于提供普适的API，API网关根据不同的客户端开放不同的API。比如，Netflix API网关运行着客户端特定的适配器代码，会向客户端提供最适合其需求的API。
API网关也可以实现安全性，比如验证客户端是否被授权进行某请求。

需要考虑的问题

单个微服务代码量小，易修改和维护。但是，系统复杂度的总量是不变的，每个服务代码少了，但服务的个数肯定就多了。就跟拼图游戏一样，切的越碎，越难拼出整幅图。一个系统被拆分成零碎的微服务，最后要集成为一个完整的系统，其复杂度肯定比大块的功能集成要高很多。
单个微服务数据独立，可独立部署和运行。虽然微服务本身是可以独立部署和运行的，但仍然避免不了业务上的你来我往，这就涉及到要对外通信，当微服务的数量达到一定量级的时候，如何提供一个高效的集群通信机制成为一个问题。
单个微服务拥有自己的进程，进程本身就可以动态的启停，为无缝升级的打好了基础，但谁来启动和停止进程，什么时机，选择在哪台设备上做这件事情才是无缝升级的关键。这个能力并不是微服务本身提供的，而是需要背后强大的版本管理和部署能力。
多个相同的微服务可以做负载均衡，提高性能和可靠性。正是因为相同微服务可以有多个不同实例，让服务按需动态伸缩成为可能，在高峰期可以启动更多的相同的微服务实例为更多用户服务，以此提高响应速度。同时这种机制也提供了高可靠性，在某个微服务故障后，其他相同的微服务可以接替其工作，对外表现为某个设备故障后业务不中断。同样的道理，微服务本身是不会去关心系统负载的，那么什么时候应该启动更多的微服务，多个微服务的流量应该如何调度和分发，这背后也有一套复杂的负载监控和均衡的系统在起作用。
微服务可以独立部署和对外提供服务，微服务的业务上线和下线是动态的，当一个新的微服务上线时，用户是如何访问到这种新的服务？这就需要有一个统一的入口，新的服务可以动态的注册到这个入口上，用户每次访问时可以从这个入口拿到系统所有服务的访问地址。这个统一的系统入口并不是微服务本身的一部分，所以这种能力需要系统单独提供。
还有一些企业级关注的系统问题，比如，安全策略如何集中管理？系统故障如何快速审计和跟踪到具体服务？整个系统状态如何监控？服务之间的依赖关系如何管理？等等这些问题都不是单个微服务考虑的范畴，而需要有一个系统性的考虑和设计，让每个微服务都能够按照系统性的要求和约束提供对应的安全性，可靠性，可维护性的能力。
服务容错：当企业微服务化以后，服务之间会有错综复杂的依赖关系，例如，一个前端请求一般会依赖于多个后端服务，技术上称为1 -> N扇出. 在实际生产环境中，服务往往不是百分百可靠，服务可能会出错或者产生延迟，如果一个应用不能对其依赖的故障进行容错和隔离，那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中，某个单一后端一旦发生延迟，可能在数秒内导致所有应用资源(线程，队列等)被耗尽，造成所谓的雪崩效应(Cascading Failure)，严重时可致整个网站瘫痪。

服务依赖

总结

微服务的实施是有一定的先决条件：基础的运维能力（如监控、快速配置、快速部署）需提前构建，否则就会陷入如我们般被动的局面。推荐采用基础设施及代码的实践，通过代码来描述计算和网络基础设施的方法，使得图案度i可以快速安全的搭建和处理由新的配置代替的服务器，服务器之间可以拥有更高的一致性，降低了在“我的环境工作，而你的环境不工作”的可能，也是为后续的发布策略和运维提供更好的支撑。
其他要点
系统支撑

基础

日志和审计，主要是日志的汇总，分类和查询
监控和告警，主要是监控每个服务的状态，必要时产生告警
消息总线，轻量级的MQ或HTTP
注册发现
负载均衡
部署和升级
事件调度机制
资源管理，如：底层的虚拟机，物理机和网络管理

画龙点睛

认证和鉴权
微服务统一代码框架，支持多种编程语言
统一服务构建和打包
统一服务测试
微服务CI/CD流水线
服务依赖关系管理
统一问题跟踪调试框架，俗称调用链
灰度发布
蓝绿部署

容器（Docker）与微服务

•容器够小
–解决微服务对机器数量的诉求
•容器独立
–解决多语言问题
•开发环境与生产环境相同
–单机开发、提升效率
•容器效率高
–省钱
•代码/image一体化
–可复用管理系统
•容器的横向与纵向扩容
–可复制
–可动态调节CPU与内存
•Image管理
•系统安全管理
•授权管理
•系统成熟度
•社区成熟度
由于Docker引入，不同的微服务可以使用不同的技术架构，比如Node.js Java PHP Python等，这些单个的服务都可以独立完成交付生命周期
微服务+API + 平台的开发模式，容器化微服务的持续交付概念。

首先需要考虑构建DevOps能力，这是保证微服务架构在持续交付和应对复杂运维问题的动力之源；
其次保持服务持续演进，使之能够快速、低成本地被拆分和合并，以快速响应业务的变化；
同时要保持团队和架构对齐。微服务貌似是技术层面的变革，但它对团队结构和组织文化有很强的要求和影响。识别和构建匹配架构的团队是解决问题的另一大支柱。
最后，打造持续改进的自组织文化是实施微服务的关键基石。只有持续改进，持续学习和反馈，持续打造这样一个文化氛围和团队，微服务架构才能持续发展下去，保持新鲜的生命力，从而实现我们的初衷。

参考资料
1、微服务架构下的开发部署实践
https://zhuanlan.zhihu.com/p/21563604
2、微服务与SOA：与其重用+不如抓住敏捷性http://www.searchsoa.com.cn/showcontent_88178.htm
3、Red Hat：API层是微服务架构成功的关键https://searchcloudcomputing.techtarget.com.cn/5-11978/
4、SOA和微服务架构的区别
https://www.zhihu.com/question/37808426
5、解析微服务架构
https://kb.cnblogs.com/page/520922/