论微服务架构下的软件开发和运维

本文只是探讨微服务架构下的一些想法，一家之言，请勿转载。

微服务架构的出现我觉得和mvc的设计高度相关，当一个程序用mvc架构后，分工合作就出现了，界面和工作流程也相对清晰。在原有的程序设计上，异步和同步处理都在一个程序上实现，瓶颈也就出现了，处理速度跟不上，对主机的要求越来越大，数据库的性能要求越来越高。为此能不能把计算的工作量进行分摊，把一项任务分解成多项任务，每项任务由相应的程序予以处理，这就是分布式处理。有了分布式处理，我们在实现web的应用时就有了服务的概念，对服务的内容也做了相应的分层，如IaaS、PaaS、SaaS。但有了分布式处理的服务框架，是不是就搞定一切了，我们发现在分布式处理以后，运维的处理工作大大麻烦了，原来一个服务就处理完的业务，现在是N个服务在共同处理了，而且这N个服务可能是不同的团队开发和运维的，如果你的服务足够多，你就会发现，故障的处理和服务的调度出大问题了，你真的需要时间来稳定系统了，但互联网业务的需求又是不停的推动你的服务更新，你就会一直陷入系统的不稳定和无法运维的状态。我们需要一个框架来统一分布式处理下的开发和运维工作。我任务这就是微服务架构的意义。

1 微服务架构下软件开发的要求

1.1 服务可管理

在微服务架构下，同一节点下所有的服务应该接受统一的管理，管理者可以根据需要生成、销毁服务。此类实现较为简单，比如使用统一的注册中心，对服务的参数进行统一配置，所有和服务运行及服务和服务之间的调度数据均由注册中心统一下发，对服务的全生命周期也做统一的管理。

1.2 服务可调度

在服务可管理的前提下，服务根据需要被安排在指定的环境和业务条件下工作。 此时的服务能根据调度指令在不同的资源环境和服务环境中使用，然后能自动根据所给的环境判别服务的调度请求，对资源环境、服务环境的现状实现服务的自调整。1)

1.3 业务可跟踪

在分布式处理环节中，业务被拆分成N段，我们需要对业务进行跟踪。当一个被分布式处理，我们需要的这个业务被处理的全过程展示。

1.4 服务可云化

云化含义就是在云的任何一处都能被调度，意味着服务和网络环境无关。我们所云化在我理解就是我们的服务就和云一样，哪里有需要，我的服务就出现在那里，所以，云化对于研发工作的要求就是，服务最好是无状态，有状态的服务要做尽量用切分的方式保证系统的稳定和吞吐，用数据的实时同步方式，保证服务能在多个环境中切换。

达到这四个要求了，我们说微服务架构下的软件开发基本就实现了，但这只是工作的一方面，如何把服务细分是个课题，这就是服务可云化的一个细项。除此之外，运维在微服务架构下也有相应的要求。

2 微服务架构下运维的要求

2.1 服务调度自动化

运维系统能够服务管理配置，进行服务的调度配置修改，最终实现服务的按需调度。

2.2 服务测试自动化

系统能根据要求测试服务的状态、性能、功能、服务拓扑等。

2.3 业务监控显性化

运维系统能根据业务跟踪目标，对业务的全处理过程进行管理。

2.4 监控的全景化

微服务架构下要全面监控故障对本服务及相关服务、相关业务、相关节点造成的影响，选择自动化的对应措施。