溯源SpringCloud微服务架构
引入：
软件开发是有方法的，是保证信息化时代商业盈利的必要保障；而这样的方法可以统称为架构，架构不是一蹴而就的，而是演进迭代的，没有万能的架构、只有适合自己实际需求的架构。在软件开发历史上有以下架构最终为微服务架构奠定了基础，同时列出了其本身固守的缺点：
| 架构名称 | 优缺点 |
|---|---|
| 单体架构 | 实现快、扩容代价大…… |
| 垂直架构 | 模块化、负载均衡、沟通及管理困难…… |
| SOA架构 | 服务管理、RPC技术、严重依赖服务器本身的部署能力、适配度不够…… |
| 微服务架构 | 高密度部署、原子、自治、生态圈代价很大 |
迫使CTO转向微服务架构的一万个理由(小公司没有CTO请绕过)：
单体架构的弊端：
1、模糊的模块边界导致犬牙交错
2、无数次的代码改动导致背离初衷，前期扩展性不够或者需求变化过快导致中后期需要增加功能时由于紧凑的JVM检查导致增加大量重复代码
3、很多开发人员不同的实现思路的强制糅合导致重复代码剧增
4、一旦注释有所缺失或者不够完善很可能导致死循环
5、新人需要对已有复杂的业务逻辑进行重新理解，开发人员换代导致前期培养资金剧增而企业压增,难以调整开发团队规模
6、明知前人出错但不敢修改代码导致缺口越拉越宽,最终大出血重构
7、一定程度上增大了人员的流失率，团队覆没
8、外包项目对已有项目的巨大摧残，因为外包项目大多都是其他公司为追求金钱效应赶工出来的一个临时可运行代码，其维护性、高可用性、扩展性、可负压性较低，仅满足基本效果，可一旦对其进行深刻思考便会发现无限的漏洞，很可能引起连锁的故障爆发，无法做到故障隔离
9、重型项目在升级部署时带来的压力，部署时极易失败、精准性能扩充巨难或者遭遇瓶颈、不间断服务在单体架构中的部署会有上线瓶颈（业务平滑期不复存在），最后导致不得已全线停机更新
10、阻碍了其他优秀技术的发展，因为单体架构下，技术都是一套，而业务会不停的进行增加，原始技术总是会在不停的使用，而其他非JVM技术将难以得到用武之地，如GO/NODE.JS,同时在系统集成十分困难
11、极大的降低了业务回环速度，从而错失商机，如果有竞争对手，其造成的危害不亚于被挖走了一名具有前瞻意识的高层领导。因为任何一次小的更新如果需要加入到已有业务就必须要重新部署整个应用集群，如果一天一次更新，恐怕运维不久后就会提交辞职书，而就算是使用自动化部署流程，其巨大工程极易带来部署错误，此时任是需要运维进行手动排查的。
传统SOA的不便性：
1、较为完整的流程需要依赖较多的不同公司的框架，框架设计理念不同导致集成到升级困难，意味着稳定性、可持续性差，维护这些框架的公司或者组织很可能并没有一致性的意见，而集成者只是看中其中某些功能，这将造成资源浪费情况，这在集群情况下更为严重
2、服务注册、发现、调用在某些框架上体现除了较强的通信协议的依赖，从而阻碍了宽技术的发展，例如说Dubbo,其序列化效率虽然较HTTP协议下的JSON序列化更高，但是在非Dubbo端将导致无法融合
推导出企业对维护无法上微服务的项目还需要的一些能力：
1、能读懂已有代码，并作出自己的见解
2、不畏难题，对公司忠诚度高
3、在一定压力下能随时顶替团队其他人员的能力(日企更专注的能力)
4、能够明白运行原理，研究已有框架并作出总结与改进或者开发适合业务的框架
他人对微服务的理解：
马丁·福勒(ThoughtWorks<全球软件设计与定制领袖企业>公司首席科学家，敏捷开发方式的创始人之一，国际上著名的面相对象分析设计、UML、模式等方面的专家)：从四个方面来说，拥有着这些特点，1、根据业务模块划分服务种类2、每个服务可以独立部署并且互相隔离3、通过轻量的 API 调用服务4、服务需要保证良好的高可用性。
解读：1、按业务拆分服务，这是“水平拆分”;在技术层面的“前后分离”，属于“垂直拆分”;横纵一起切，就把单一的应用拆分成网状的小块应用，这是微服务中“微”思想的体现。2、独立部署与互相隔离，这点充分体现了“我为人人、人人为我”的设计理念，这是微服务中「服务」思想的体现。3、关于轻量 API，微服务本身是推荐使用轻量的通讯协议和简单的数据结构，实际上，实施环节通常采用的都是 http+json 的方式。这样做的好处是，服务之间不再需要关心对方的模型，仅通过事先约定好的接口来进行数据流转即可，大大提高内部服务的适配性。这是微服务中“解耦”思想的体现。4、一.在技术层面上讲，根据实际运行情况下的物理需求情况对块状应用做快速扩容，从而可以提高服务的高可用性。二.在管理设计层面上讲,经由设计->开发->测试->部署的全面模式到并行开发分块实现的微模式，由于小块应用其天生具有的简洁性使得开发效率更高，由http接口带来的功能供需可以减少沟通成本，由于具体响应的应用很小，响应速度更快，由于在开发过程中由于需求变化可以更快的定位修改，从而可以减少小版本改进带来的弊端，从而使得迭代周期更短。
我对微服务的理解：
同时由业务的水平拆分、技术的垂直拆分所形成的网形块状应用，其具备高独立（部署、维护、扩展、技术栈、模式、规范、物理资源需求比）、高隔离（由宽松的HTTP协议定义接口，更低耦合、更快的升级方式）等特点。
那么，从笼统概念上来说要如何去实现微服务思想的架构：
1、业务拆分，体现在设计环节：在设计的时候，要有足够的判断力来合理的规划服务之间的界限。
2、服务治理，底层技术的支持：首先要选一款适合自己实际情况的分布式服务基础框架，对于服务的发现、治理、熔断、降级，都要做好相应的技术准备。
3、自动测试，一定要自动化。微服务一个明显的表象就是随着服务的增多，如果继续沿用传统的测试模式就会遇到瓶颈，为了保证高效的迭代，尽量做到更多的环节实现自动化。
4、自动运维 ：微服务拆分之后，每个服务都可以独立部署，进而言之应该是随时随地可以升级。尤其当互联网发展到今天，业务要保持对市场变化的一个高效响应，自动化运维就是提升交付速度的一个重要环节。
5、监控：包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话：没准备好监控，就不要搞微服务。
同时要警惕微服务带来的弊端：
1、远程调用带来的性能损耗。基于进程的调用到远程HTTP调用会带来严重的性能损耗，同时每一次链式调用所在HTTP协议下传递的变化的数据都是一次极大的损耗。
2、强一致性到最终一致性的妥协。在任何时间从任何节点读取的数据都要一致到随着时间的推进向着最终数据的一致性的趋势演进（例如DNS系统的缓存过期请求中央缓存）
3、跨服务的测试将更加复杂
4、运维工作更具挑战性
5、需要强大的整体规划性。因为其中需要规避很多东西，例如分布式事务问题，后续升级问题等等
SpringCloud日趋完善的生态圈
SpringCloud对业务的完整实现流程
SpringCloud特有的辅助功能
基于SpringCloud实现几个典型的的核心业务
必须解决的关于SpringCloud带来的其他问题
分布式事务
数据库扩容
SpringCloud所有组件源码分析优化到适配自身业务
对未来的展望
留给自己的话
好的文章不是写出来的，而是改出来的。
参考的资料
| 名称 | 外网URL |
|---|---|
| 从源头入手，一分钟秒懂为什么要搞微服务架构？ | http://developer.51cto.com/art/201707/545735.htm |
| 什么是数据库的一致性？一致性弱意味着什么？NoSQL 的弱一致性又为什么是可以被接受的？ | https://www.zhihu.com/question/20113030 |