认识微服务

#单块架构
在认识微服务之前，首先认识一下`单块架构`，很多互联网公司在创业初期都是采用`单块架构`，单块架构里将应用分成三层，表示层，逻辑层，访问层(数据)。然后部署在同一web容器上。
![title](https://leanote.com/api/file/getImage?fileId=57d39976ab64416b550018e6)
在单体架构里，以上能表示应用的所有代码，公司每个部门的人都在为这个代码仓库贡献代码，久而久之，代码变得非常庞大，笨重。每个部门的工作效率，交付能力变得越来越收到限制。主要表现为：
```
维护成本增加
交付周期长
新人培养周期长
技术选型受限制
扩展性差
构建全能团队难
```
为了改变这种现状，目前很多公司在尝试采用`微服务`去改造。但是，我们也可以得出，在创业初期其实是不适合做微服务的，因为创业初期需要以业务为主，本身业务不复杂的情况下很难拆分。但是，具备一定规模的公司微服务是相当有必要的。
#什么是微服务
微服务目前为止很难有一个准确的定义，但是每个实践微服务的开发者目标是一致的。这里引用ThoughtWorks首席科学家——Martin fowler的一句话
>微服务是一种架构模式，它倡导将单一应用程序划分成一组小的服务，服务之间相互协调，相互配合，为用户提供最终价值。每个服务运行在独立的进程中，服务与服务之间采用轻量级通信机制相互沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能独立部署到生产环境，类生产环境等。每一个具体的服务而言，可以选择合适的语言和工具进行构建。

##单一职责
如果你使用过Linux命令行，比如要找出当前目录下占用空间最多的5个资源
```
du -s * | sort -nr | sed 5q
```
可以看到，这段命令行就是将几个常用的指令拼合起来完成任务。同样，在微服务架构中，也是这样的思路。对每个服务而言，我们希望它处理的业务能够单一，也就是说，微服务架构中的每个服务，都是具有业务逻辑的。不同的服务通过"管道"的方式灵活组合，从而构建出庞大的应用。
##轻量级通讯
由于微服务化之后，每个微服务内部都可能采用不一样的语言，不一样的框架，所以微服务之间的通信尽量采用和语言无关，平台无关的方式。
![title](https://leanote.com/api/file/getImage?fileId=57d3a3a3ab6441695200182c)
对于轻量级通信格式而言，我们属性的XML或者JSON，他们的解析和使用基本与语言无关，平台无关。对于轻量级通信的协议而言，通常基于HTTP，它能让 服务之间的通信标准化并且无状态化。
##独立性
独立性是指在应用的交付过程中，开发和测试以及部署的独立。对于每个服务，都有独立的代码库，包括构建包也是独立的，部署也自然而言就独立部署了
![title](https://leanote.com/api/file/getImage?fileId=57d3a5e6ab64416b55001976)
比如上图中的两个服务，他们的开发， 测试，构建，部署，都是互不影响的。从这一点可以看出，微服务对团队的要求特别高，通常是一个比较强大的团队撑起一个服务。
说到独立性，对一个服务而言，开发者团队将负责以下事情
```
开发
部署
监控
```
换句话说，开发者将承担起服务整个生命周期的责任。至于运维，DBA，他们只是顾问式的角色。
#微服务带来的改变
在微服务实施的过程中，团队，包括开发方式都将带来改变。同时，也需要考虑一下因数
1. 分布式系统的复杂度
2. 运维成本
3. 部署自动化
4. DevOps与组织架构
5. 服务间依赖管理
##分布式系统的复杂度
1. 性能，由于服务之间的调用时跨进程，垮网络的，必然存在网络延迟和宽带的影响。所以，当业务需要多个服务相互协作的时候，需要考虑响应时间和性能对系统的影响
2. 可靠性，在分布式系统中，由于网络，宽带，节点自身的影响，任何一次远程服务调用都可能失败。如何提高系统的可靠性也增加了系统构建的难度
3. 异步，我们知道，同步通信的过程一般是发送请求，接受响应并处理，整个过程实现简单，但回造成阻塞。显然这种方式并不适用于多次网络调用，因为响应时间回线性增长
##运维成本
1. 配置，主要包括应用相关的配置信息，比如参数，依赖部分，数据库地址，缓存地址等
2. 部署，将制定代码部署到制定的环境中
3. 监控和报警，主要包括应用的健康状态进行监控，并能发现故障及时告警
4. 日志收集，要提供日志收集和检索方式，做到能通过日志快速定位问题
##部署自动化
随着微服务的增多以及实现方式的多样性，部署必须不能手动进行。得有一个自动部署的平台，将制定服务打包部署到相应的机器上。
##DevOps架构调整
每个微服务的团队职责有所改变，开发团队要支撑起服务的整个生命周期，开发团队必须是强大的，基本上要做到能解决任何问题
##服务间依赖管理
随着服务的增多，如何清晰的描述服务之间的依赖关系，成为了一个很大的挑战，在变更服务的时候，如何能通知到所有依赖自己的服务，也变成了一个很大的挑战。

Navigation

Recent Posts

Friend Links