软件技术架构变迁

　　今天从一个软件行业从业者的角度分析软件技术架构的变迁（升级）的一些看法。软件技术架构从原始阶段的单体架构升级至成熟阶段的微服务架构，主要经历了如下几次变迁：
　　微服务架构演变过程
　　一、1940年1990年期间，原始阶段。
　　从研究发明了机器语言到独立细分的软件语言诞生，如：VB、QBase、C、C、HTML等，原始阶段近50年。软件技术研究的重点主要在软件的应用范围、软件的开发便捷性上，使软件语言能够更好的支持操作系统平台及环境，增强功能，提高编码效率，提升程序可用性，使该软件语言在占有商业市场份额上具有一定优势。这期间人们对于软件的分层及架构应用无暇顾及。
　　错综复杂的编程语言
　　二、1990年2010年期间，萌芽阶段。
　　随着科技的不断发展，软件技术语言也在这期间迎来了蓬勃发展，相继诞生了很多优秀的技术语言，如支持跨平台的、组件丰富的、硬件交互强大、支持移动端的等等。这期间，技术语言的功能性相对完善，市场份额也相继瓜分完毕，技术语言的研究重点开始转移，新发明的语言开始注重集百家之长，摒弃其他技术语言中的存在的缺点。这时候市面上的技术语言应用架构往往都还以单体架构、垂直架构为主。根据特定需求，通过应用集群模式，解决软件系统性能问题。
　　单体架构集群模式
　　单体架构
　　优点：系统开发速度快；维护成本低；适用于并发要求不高的系统环境；
　　缺点：无法水平扩展；代码耦合度高，系统维护困难；单点容错率低，并发能力差。
　　三、2010年2015年期间，发展阶段。
　　2010年左右开始，随着高新技术的蓬勃发展，IT软件开发从业人员激增，IT服务供应市场供大于求，导致IT服务行业竞争激烈。市场对于IT软件诉求由功能性、友好性、应用便捷性的基本需求，转变为可扩展性、可持续性、可维护性、安全性、用户体验等多方面的要求。其中，可扩展性、可维护性又需要根据企业客户的持续发展需求，可动态扩展或升级，IT服务商需要综合考虑企业客户的业务发展、软件访问量、数据量、系统持续升级、建设成本等多维度问题，提供一套完善的解决方案。
　　IT服务商
　　在原有单体架构下，软件性能、系统升级、建设成本很难做到完美平衡。往往容易出现，系统性能规划较好，投入成本过高，系统实际使用率不高；或系统性能规划一般，系统建设成本一般，但随着业务的较快增长，导致系统现有性能设计无法支撑，只能重新规划新建软件系统进行替换。这期间互联网TOP公司大咖们陆续想出了一些解决问题的思路，如：硬件优化、应用集群、数据库集群、数据缓存、消息中间件、SOA、分布式等，从各个角度对性能及扩展性予以解决，但是始终没找到最合适的解决方案。
　　tomcat应用集群
　　分布式架构
　　优点：将系统基础应用按照SOA进行抽取，将应用化的服务通过系统间相互调用，提高了代码开发效率和复用率。
　　缺点：在无企业服务总线的基础上，系统间耦合度变高；否则过度依赖于企业服务总线（ESB）统一管理服务接口，ESB对服务的管理能力要求过高，所有服务需遵循ESB的统一规范对接，接口适配性不强。
　　三、2015年2022年期间，成熟阶段。
　　随着服务化、分布式、微服务的概念在这期间为IT行业所熟知，在这段时间内，人们通过不断的实践与总结，将服务化与集群、事务、代理、数据缓存等概念合并应用，终于找到了最佳解决方案。微服务在这段期间内，开始为主流所接受，应用市场也得到了广泛的推广。其中，SpringCloud与Dubbo又因为组件丰富、功能强大、适配性强等因素，成为当前IT行业主流的微服务架构。
　　微服务技术架构
　　微服务架构
　　微服务技术架构是将单个应用服务作为一套小型开发程序的方法，每套应用程序都在自己的进程中运行，采用一组服务的方式来构建一个应用，服务独立部署在不同的进程中，不同服务通过一些轻量级交互机制来通信的架构思路。
　　特点：
　　独立性
　　每个微服务基本上都是独立的项目，而对应独立项目的研发团队也是独立的，这样的结构保证了微服务的并行研发，并且各自快速迭代，
　　可扩展性
　　可以快速地添加服务集群的实例，提升整个微服务集群的服务能力，而在传统模式下，为了提升服务能力，必须强化和扩展单一结点的服务能力来达成。如果单结点服务能力已经扩展到了极限，再考虑扩展的话，需要从软件到硬件整体进行重构。
　　隔离性
　　隔离性实际上是可扩展性的基础，当我们将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，而不会影响整个服务运行体系。
　　服务独立维护，分工明确
　　每个微服务都可以交由一个小团队进行开发，测试维护部署，并对整个生命周期负责，将每个微服务都隔离为独立的运行单元之后，任何一个或者多个微服务的失败都将只影响自己或者少量其他微服务，不会波及整个应用。
　　微服务的不足：
　　微服务应用是分布式应用，由此会有一些复杂性。需要在RPC或者消息传递之间选择并完善进程间通讯机制。
　　谢谢大家！