1.2 微服务分布式
微服务工程将众多框架通过一个入口集成到自身的程序中，让编程人员不需关注框架原理即可直接进行调用。当初的SSM类项目也基于相同的思想，但当SSM类项目集成的框架过多后，配置文件数目与日俱增且难以管理，而此时Spring Boot微服务赋予了它们所需基本配置参数的大部分框架和工具，将初始配置参数的压力再次缩减。
分布式架构将不同的业务模块通过不同的服务器运行，曾经的多个WebService组建的SOA架构的项目也基于相同的思想，而此时的Spring Cloud把过去的架构变得更加简便、轻松。
从SOA类项目开始将大型应用程序拆分成多个独立运行的小型应用程序，多个应用程序之间由WebService协议进行通信。因为每个WebService服务还要集成SSM，甚至每个服务还要做相关的管理页面和各种监控，所以每个WebService服务开发的过程都比较冗长。
微服务架构下的每个微服务和WebService一样都是独立运行的，将复杂的业务以模块的形式拆开，方便开发人员编写。微服务通常使用Spring Boot进行快捷开发，大部分基础信息在Spring Boot的底层之中都已经被配置好了，不像SSM一样需要编写大量XML程序，因此每个微服务在编程的过程中都会十分快速。
1.2.1 Spring Boot微服务的定义和特点
Spring Boot微服务可以轻松地创建独立的产品级应用程序。Spring平台和第三方库采取自行管理的方式，可更加便捷地开始编写应用程序。Spring Boot通过pom.xml文件，依赖Spring Boot的Starter，将所有需要的Jar包集中在一起。Spring Boot微服务替代了原本的Spring+SpringMVC/Struts2+MyBatis/Himbernate结构。
Spring Boot做了很多配置文件的管理。原本需要写三四个Application.xml文件，对数据库资源池、事务、服务、视图、静态资源等进行配置，现在则完全不需要，而事实上与以前做的传统项目大部分的配置文件也没有较大的区别。
打包变成了直接运行的Jar包，因为包变小了，包内所提供的内容更加清晰明确，所以称为微服务，特点如下。
● 创建独立的Spring应用程序。
● 直接嵌入Tomcat、Jetty或Undertow（不需要部署war文件）。
● 提供被约定好的Starter依赖内容，以简化构建配置。
● 尽可能自动配置Spring和第三方库。
● 提供产品在生产过程中所需要的如健康检查和外部化配置等。
● 没有绝对的代码生成，也不需要XML配置。
Spring Boot的部署简单，只要服务器有Java环境便可运行，即使再多的服务器也能快速且稳定运行。
Spring Boot的设计初衷是约定大于配置，过多的重复性配置压力在SSM里让人深有体会，每个SSM项目中的XML大部分内容都是类似的，对于资深程序员来讲，任何一个新项目的编写都是一个复制粘贴的过程，而Spring Boot省略了初始化配置和重复性配置的过程。
1.2.2 Spring Boot的职场导读
如今Spring Boot+Spring Cloud的微服务分布式项目架构，如同当年的SSM类架构一样，属于1～3年工作经验Java Web研发程序员找工作的必备技能之一。通常初级Java Web研发职位的技能要求如下：
（1）熟练掌握Java后台编码基础技术，如JVM、语法、GC、多线程、IO、网络编程、反射等；
（2）熟练掌握Spring Cloud与Spring Boot架构开发；
（3）熟悉Spring、SpringMVC、MyBatis等开源框架，最好了解其中部分源码；
（4）熟悉Tomcat、JBoss、Weblogic等主流应用服务器；
（5）熟悉HTML、CSS、JavaScript，JQuery等前段基础知识；
（6）熟悉Oracle或MySQL数据库开发，如SQL与存储过程；
（7）熟练使用Linux操作系统，掌握基本Shell命令；
（8）熟练掌握Radis、MongoDB；
（9）熟练使用WebService主流框架，如CXF、Axis等；
（10）熟练使用Maven、Git、SVN等相关版本控制工具。
目前，主流的架构通常用Spring Boot+Spring Cloud作为程序后台，用VUE或AngrulJS作为程序前台，达到VUE+Spring Boot+Spring Cloud前后台分离的架构模式，Java程序员再不需要关心JSP等前台相关内容，这些都由前端人员自行管理，减轻了沟通成本，也减轻不少编程和维护上的压力。
微服务类框架除了Spring Boot，还有JFinal、JBoot等国产微服务框架。
1.2.3 Spring部分内容
如表1-1所示，Spring的常用框架有很多种，而且Spring定制了大多分布式架构所需的工具与框架。Spring已经替编程人员完成了分布式的架构，而分布式编程人员在其中挑选一些适合项目的工具并参照操作文档进行集成即可。
表1-1 Spring的常用框架
续表
续表
1.2.4 微服务的拆分
微服务将整个大型Web项目拆分成了多个小型的Spring Boot工程，彼此依靠Spring Cloud相关分布式框架工具进行整合，通常编程人员将一个大项目中不同的业务和技术分别拆分成不同的小模块进行独立运行。例如，一个已上线的项目一般包含以下微服务工程。
（1）zfx_account微服务工程：关于账号、鉴权、缓存的微服务。
（2）zfx_admin微服务工程：微服务自身的控制管理服务。
（3）zfx_service微服务工程：给外部系统提供服务的微服务。
（4）zfx_control微服务工程：业务监控、性能监控的微服务。
（5）zfx_mobile微服务工程：给手机端提供接口的微服务。
（6）zfx_produce微服务工程：管理自身产品的微服务。
（7）zfx_message微服务工程：邮件、短信通知的微服务。
（8）zfx_pay微服务工程：对接支付接口的微服务。
（9）zfx_mq微服务工程：给其他微服务提供消息队列功能的微服务。
（10）zfx_common微服务工程：通常实体类都存在common中，别的项目会依赖common，common中存放其他微服务共通性的工具。
（11）zfx_parent微服务工程：别的项目会依赖parent，通常在parent中不会编写实际意义的代码，parent主要定义相关框架的版本信息等相关内容。
（12）zfx_paytran微服务工程：支付相关的微服务。
（13）zfx_dataaccess微服务工程：一些数据库增删改查外的索引管理、数据库心跳及预警等相关功能的微服务。
上述拆分中每个微服务项目都是一个独立运行的Spring Boot工程。每个Spring Boot工程之间依靠注册中心进行关联，依靠Feign进行相互通信，依靠Spring Cloud Security进行鉴权和单点登录。
不同的业务场景所需要进行拆分的业务模块和技术模块肯定不同，通常根据自身的业务进行调整，不过像zfx_parent、zfx_common肯定是系统必备的内容。因为一个工程中再多的业务也必须有互相需要依赖的Jar包、提取的共同点、共同需要的技术内容，所以在微服务拆分时可先将parent和common两个模块拆分出来，抽出程序的共通性，再慢慢新增其他的服务模块。
线上项目拆分成40～50个微服务工程是正常现象，因此在做分布式微服务项目架构时，只要维护管理到位，就不用担心微服务的数目是否过多，如果重用性得当，让每个程序员管理其中几个微服务，就能达到以最快速度开发迭代的目的。
移动端使用H5，再利用Android和iOS的Webview整合H5进行混合开发，大部分内容在Android与iOS之间都不需要重新编写，即一套页面在两个系统中使用，不需要重复开发。