开发语言

语言：人与人交流的沟通表达方式

计算机语言：人与计算机之间交互沟通的语言

语言分类

按照与自然语言的差异分类

• 低级语言
  • 机器语言、汇编语言都是面向机器的语言，都是低级语言。不同机器是不能通用的，不同的机器需要不同的机器指令或者汇编程序
• 高级语言
  • 接近自然语言和数学语言的计算机语言

常见语言

• C语言
  • 面向过程编程，只有函数
  • 操作系统编程、单片机编程等领域
• C++语言
  • 底层高性能开发
  • 面向对象，学习难度极大，目前标准发展有点乱
• Java
  • WEB开发领域第一，延伸领域极多，库丰富
  • 大数据领域生态完整
• Python
  • 入门门槛低，深入并不容易，非专业程序员容易接受，他们有丰富的专业知识，但计算机专业知识不够
  • Python简洁的语法，不需要让他们关注背后的细节，可以让他们较容易的掌握并开始编程
  • 运维开发
• Javascript
  • 网景公司发明的动态脚本语言，前端开发第一语言
  • JavaScript才是目前前后端通吃的全栈语言
  • 前端执行的JS代码，需要从服务器端发送到浏览器端，在浏览器端使用JS引擎执行
• Go
  • C语言之父Ken Thompson亲自参与设计
  • 静态编译型语言，但结合了动态解释性语言的特点，例如GC
  • 充分利用多核，适合高并发场景

WEB架构

web资源和访问

后端资源分类

• 静态资源
  • 图片：一旦创建好，图片文件不再改变。图片数目多，占用磁盘空间多，一般使用单独的图片服务器
  • HTML、CSS、JavaScript：这些文本是文本的，前端工程师可以修改，但修改次数较少，一段时间都不变
• 动态资源
  • 内容有后台程序动态生成，比如查询数据库，将查询结果生成为HTML

访问web的方式

PC端或移动端浏览器访问

从静态服务器请求HTML、CSS、JS等文件发送到浏览器端，浏览器端接收后渲染在浏览器上
从图片服务器请求图片资源显示
从业务服务器访问动态内容，动态内容是请求后有后台服务访问数据库后得到的，最终返回到浏览器端

WEB App访问
内置了HTML和JS文件，不需要从静态WEB服务器下载JS或HTML。为的就是减少文件的发送，现代前端开发使用的JS文件太多或太大了
有必要就从图片服务器请求图片，从业务服务器请求动态数据

客户需求多样，更多的内容还是需要由业务服务器提供，业务服务器往往都是由一组服务器组成。

后台应用架构

单体架构

• 传统架构（单机系统），一个项目一个工程：比如商品、订单、交易、库存等等，统一部署，一个进程
• Java实现：JSP、Servlet，打包成一个jar、war部署
• web应用服务器：开源的tomcat、jetty、glassfish。商用的有weblogic、websphere、Jboss

微服务

• 属于SOA（Service Oriented Architecture）的子集
• 微服务化的核心就是将传统的一站式应用，根据业务拆分成一个一个的服务，彻底去掉耦合，每一个微服务提供单个业务功能，一个服务只做一件事。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等
• 从技术角度讲就是一种小而独立的处理过程，类似与进程的概念，能够自行单独启动或销毁
• 微服务架构（分布式系统），各个模块/服务，各自独立出来，“让专业的人干专业的事”，独立部署。分布式系统中，不同的服务可以使用各自独立的数据库。
• 服务之间采用轻量级的通信机制（通常是基于HTTP的RESTful API）。
• 微服务设计的思想改变了原有的企业研发团队组织架构。传统的研发组织架构是水平架构，前端、后端、DBA、测试分别有自己对应的团队，属于水平团队组织架构。而微服务的设计思想对团队的划分有着一定的影响，使得团队组织架构的划分更倾向于垂直架构，比如用户业务是一个团队来负责，支付业务是一个团队来负责。但实际上在企业中并不会把团队组织架构拆分得这么绝对，垂直架构只是一种理想的架构
• 微服务的实现框架有多种，不同的应用架构，部署方式也有不同

单体架构和微服务比较

微服务的优缺点

微服务优点：

-每个服务足够内聚，足够小，代码容易理解。这样能聚焦一个只当的业务功能或业务需求。
-开发简单、开发效率提高，一个服务可能就是专业的只干一件事，微服务能够被小团队单独开发，这个小团队可以是2到5人的开发人员组成
-3.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的。

-微服务能使用不同的语言开发

-易于和第三方集成，微服务运行容易且灵活的方式集成自动部署，通过持续集成工具，如Jenkins、Hudson、Bamboo

-微服务易于被一个开发人员理解、修改和维护，这样小团队能够更关注自己的工作成果，无需通过合作才能体现价值

-微服务允许你利用融合最新技术。微服务只是业务逻辑的代码，不会和HTML/CSS或其他界面组件混合，即前后端分离

-每个微服务都有自己的存储能力，可以有自己的数据库，也可以有统一数据库

微服务缺点：

-微服务把原有的一个项目拆分成多个独立工程，增加了开发、测试、运维、监控等的复杂度
-微服务架构需要保证不同服务之间的数据一致性，引入了分布式事务和异步补偿机制，为设计和开发带来一定挑战
-开发人员和运维需要处理分布式系统的复杂性，需要更强的技术能力
-微服务适用于复杂的大系统，对于小型应用使用微服务，进行盲目的拆分只会增加其维护和开发成本

常见的微服务框架

*Dubbo

• 阿里开源贡献给了ASF，目前已经是Apache的顶级项目
• 一款高性能的Java RPC服务框架，微服务生态体系中的一个重要组件
• 将单体程序分解成多个功能服务模块，模块间使用Dubbo框架提供的高性能RPC通信
• 内部协调使用Zookeeper，实现服务注册、服务发现。有服务治理

Spring cloud
一个完整的微服务解决方案，相当于Dubbo的超集

*微服务框架，将单体应用拆分为粒度更小的单一功能服务

*基于HTTP协议的REST(Representational State Transfer 表述性状态转移）风格实现模块间通信

本文链接：https://www.yunweipai.com/35096.html