导语
喜欢踢球的同学一般知道这样的一个段子，当年有好事的记者问风头正盛的球王马拉多纳，在他进球中，哪个踢得最精彩？马拉多纳想了想就说：“一个吧”所以，努力追求“下一个”是一个普通球员到天才球员的必备品质，那么在快速互联网行业中同样如此，每一次的技术更新变革也意味着无数个追求“下一个”的互联网从事着的日日夜夜的辛勤劳动。
第一章 软件架构演进
按照不同阶段使用的软件架构来排序：单体架构，垂直架构，服务化架构，微服务架构以及未来可能出现的无服务架构（ServiceLess）以及服务网格（Service Mesh）。
1.单体架构
单体架构在初创的小微企业比较常见，典型代表就是一个应用、一个数据库、一个Web容器就可以跑起来，但现在实际的。
特点：
所有功能集中在一个项目工程中，所有的功能在一个war包中，然后部署到服务上，并且可以通过集群来提高系统的性能瓶颈。
优点：
①部署实施简单，可以保证项目快速上线。
②项目架构简单，前期开发成本低，周期短。
缺点：
①全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
②系统性能扩展只能通过扩展集群结点，成本高。
2.垂直架构
每一个垂直模块属于一个单一团队，通过垂直拆分，原来的单体项目不至于无限扩大。在模块之间共享代码是严令禁止的。出现了影响力最大设计典范MVC模式，模型(model)－视图(view)－控制器(controller),SSH框架是典型的MVC设计思想的应用框架。
特点：
垂直架构思想在于分层。
优点：
①隐藏下层的实现。下层为上层提供其所需的服务，但实现的过程，上层是无法知晓的。
②不同的项目可采用不同的技术。
③代码的复用性得到极大提高。
缺点：
①上下层级相互依赖，牵一发而动全身。
②全部功能集成在一个工程中，对于大型项目不易开发、扩展及维护。
3.服务化架构
SOA代表面向服务的架构，将应用程序根据不同的职责划分为不同的模块，不同的模块直接通过特定的协议和接口进行交互。这样使整个系统切分成很多单个组件服务来完成请求，当流量过大时通过水平扩展相应的组件来支撑，所有的组件通过交互来满足整体的业务需求。
特点：
在系统的角度，解决两个核心的问题，程序的通讯问题以及服务化的构成。由于服务化架构使用的RPC通讯的方式，所以也被很多人称为RPC框架,RPC是远程调用，RPC是服务化架构的核心，在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC，WebService等通讯方式使得服务化的分布式基础。
优点：
①将重复的功能抽取为服务，提高开发效率，提高系统的可重用性、可维护性。②采用ESB减少系统中的接口耦合。
缺点：
①抽取的服务的粒度过大，系统与服务之间耦合性高。
②系统与服务的界限模糊，不利于开发及维护。
软件架构演进总结：单体架构是最早最行之有效的软件架构，也是对以后的架构发展的基础；在单体架构发展一段时间后，公司的业务量和业务层级开始需要更高的要求， 在这一阶段单体架构的增加机器带来提高瓶颈的功能越来越小，最后只能将系统分为不同的层级，每个层级有对应的职责，以提升效率；如果公司进一步的做大，垂直子系统会变的越来越多，系统和系统之间的调用就不能避免了，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，以便应用更快速度的响应多变的市场需求。
第二章 微服务架构
其实服务化架构已经可以解决大部分企业的需求了，程序之间可以通讯了，逻辑上服务也分离出来了，那么我们为什么要研究微服务呢？微服务架构是SOA架构思想的一种扩展，更加强调服务个体的独立性、拆分粒度更小。
微服务的定义
将大型的复杂应用分解为多个小的微服务，每个微服务都围绕着具体业务进行构建，各微服务可分布式独立部署，且服务之间互相协调、互相配合，实现应用的快速迭代。
微服务的优点和缺点
优点：能够独立完成相应的服务，不再相互牵制。
缺点：微粒度越高，维护的成本越高。
微服务的价值
微服务的价值按照职位不同的角度来阐述的话，对于运维，开发人员，测试人员来说，是能提高工作效率的系统或者是工具；而对于CTO，技术管理者来说，微服务架构能够解决部分管理问题，合理的微服务抽象和拆分对应合理的组织结构划分，每个服务就变成一个独立的小产品，运营这个产品就是组织主要目标，产品的价值决定部门的价值，产品用户的多少决定组织价值的高低，这种类似市场化的管理方法是最能提供明确的指导性，战略性。
服务化架构与微服务化架构对比
1.通讯方式对比
服务化架构采用的RPC通讯方式，而微服务架构采用的是REST的通讯方式。RPC通讯是基于TCP传输层协议的产物（7层协议中的第三层），但像很多对DUBBO二次开发的的框架同样也支持HTTP，例如当当网的DUBBOX。RESTFUL通讯方式是基于HTTP应用层协议的产物。RPC是以动词为中心的, REST是以名词为中心的, 此处的动词指的是一些方法, 名词是指资。以动词为中心,意味着,当你要需要加入新功能时,你必须要添加更多的动词, 这时候服务器端需要实现相应的动词(方法), 客户端需要知道这个新的动词并进行调用。而以名词为中心, 假使我请求的是 hostname/friends/, 无论这个URI对应的服务怎么变化,客户端是无需关注和更新的,而这种变化对客户端也是透明的。
2.典型框架对比
DUBBO是SOA架构时代的产物，但国内技术人喜欢拿DUBBO和微服务架构SPRING CLOUD进行对比，是因为两者都是服务治理非常优秀的开源框架。DUBBO系出名门，是2008年底在阿里内部开始规划调用，2011开源的服务化治理的核心框架，2013年中途停止过，2017年9月份又重启维护并发布了新版本并被广泛应用于阿里巴巴集团的各成员站点。同时阿里云也推出了企业级分布式应用服务EDAS，为DUBBO提供应用托管。SPRING CLOUD，从命名我们就可以知道，它是SPRING SOURCE的产物，SPRING社区的强大背书可以说是JAVA企业界最有影响力的组织了，而为其提供技术后盾是Netflix公司(https://netflix.github.io/)，在中国也叫网飞。Netflix也是非常有传奇色彩的公司，最开始是在线影片租赁，后来开始自制剧，著名的纸牌屋就是出自网飞，去年还买下了白夜追凶的播放版权。就目前请看看来说，阿里的DUBBO知名度更高一些，一个可能这也与早年阿里就开源了DUBBO框架之外，另一个原因是不少科技公司的架构师或者是主程均出自阿里系习惯了阿里的内部框架。随着技术的发展，大家可以关注两个框架的发展情况。
3.框架选型
可以打个比方。SPRING CLOUD品牌机，DUBBO是组装机；品牌机的兼容性有保证，开机即用。组装的机子更*，选购自己心仪的CPU，内存条，硬盘等资源，但是需要一定技术能力去规划组装。但总的来说，微服务是未来发展的大趋势，有意更换架构的企业可以尽早做好打算。
第三章 Spring Cloud与DevOps实战
Spring Cloud
Spring Cloud是一系列框架的有序集合，它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发，如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等，都可以用Spring Boot的开发风格做到一键启动和部署。Spring 并没有重复制造*，它只是将目前各家公司开发的比较成熟、经得起实际考验的服务框架组合起来，通过Spring Boot风格进行再封装、屏蔽掉了复杂的配置和实现原理，最终给开发者留出了一套简单易懂、易部署和易维护的分布式系统开发工具包。Spring Cloud是微服务最典型也是目前应用最广泛的架构。
所有请求都统一通过 API 网关(Zuul)来访问内部服务；网关接收到请求后，从注册中心(Eureka)获取可用服务；由Ribbon进行均衡负载后，分发到后端的具体实例；微服务之间通过Feign进行通信处理业务；Hystrix负责处理服务超时熔断；Turbine监控服务间的调用和熔断相关指标。
CI/CD
CI持续集成，CD持续交付，通常会采用一些软件如Jenkins、TeamCity等来辅助项目流程。CI/CD能够与Git SVN等代码管理仓库集成，帮助使用者实现自动化任务。CI/CD是DevOps中最重要也是最典型的实际应用。
Spring cloud与DevOps结合
Spring cloud与DevOps不是先有鸡还是先有蛋的问题，而是相互利好的关系。DevOps就是直击Spring cloud的痛点，把最复杂的分布式的服务，进行高效持续的生产。使用Spring cloud，第一步是要构建一个一体化的DevOps平台，试想如果不使用DevOps做微服务的话，整个环境会变得非常的乱、非常的糟糕，Spring cloud会给你的整个开发、测试和运维增加很多成本，反而是得不偿失了。所以第一步我们是提高DevOps的能力，能够把它的开发、部署和维护进行很完美的结合，才可以说我们真正能够享受到Spring cloud框架的福利。
技术流程（手动打包）
1.Jenkins从仓库中手动拉取最新代码。
2.通过Jenkins的自带插件打包编译代码。
3.进行单元测试。
4.build构建最新的容器镜像。
5.push镜像到镜像仓库中去。
6.使用K8S或者docker-compose等容器编排工具进行项目的启动。
第四章 思考
中小企业新技术的选择思考
1.永远不要优先考虑性能问题，等到有性能问题，使用负载均衡。等到负载均衡搞不定时，公司也大了，就说融资上市的事情了，那就有新的技术架构技术方案代替原来的。
2.优先考虑的是文档/社区/可维护性。
3.优先选择硬通货，一旦有问题不仅仅是你一个人有问题，可以去Stack Overflow找答案；可以参考swarm和K8S的情况。
微服务的可实施性思考
我的总结观点是：不要为了追求技术而追求技术。稳定而有效的结果才是我们的最求，例如我维护过做游戏的日本客户，到现在都还在使用Windows Server 2013系统。
1.团队的技术人员是否已经具备相关技术基础。包含了对微服务的理解，DevOps的掌握等等都需要过硬的技术实力。
2.公司业务是否适合进行微服务化改造，并不是所有的平台都适合进行微服务化改造，比如：传统行业有很多复杂垂直的业务系统。而且要涉及到整个业务的数据库的分表分库，重新统一服务接口，最后还要规划具体的容器实施部署。
3.Spring Cloud 生态的技术有很多，并不是每一种技术方案都需要用上，适合自己的才是最好的。
运维行业的思考
新的技术发展到现在，给我最深的感触就是基础性的技术支持越来越被隐藏，更多的是强调自身业务快速实现和拓展。国外像Netflix和亚马逊是压根就没有运维这样的角色，运维的事情都是由开发工程师来完成，他们的职位名称是SDE(Software Develop Engineer)，所以他们也被戏称为Someone Do Everything。所以，运维转型不是一句吓唬人的话，真的已经在我们身边发生了。
总结
技术变革的根本原因是业务发展的瓶颈与突破，技术能力决定业务能力的宽度，业务能力决定公司的长度；当技术能力达到一定高度的时候，可以试着调整自己的思考角度，从产品，从业务发展来考虑，又可以看到不一样的风景。